Your campaign still contains a page.link URL. A customer taps it, receives an error, and never reaches the product, invitation, or offer that was promised. If you are repairing a deep link Firebase implementation after the shutdown, swapping one SDK is not enough: you must recover the old routing rules, choose what will replace each Firebase Dynamic Links capability, rebuild the links, and verify every installed and uninstalled path.
How do you replace Firebase Dynamic Links? Inventory your old links and their parameters, then implement verified Android App Links and iOS Universal Links for users who already have the app. If you also need store routing, deferred deep linking, short links, or campaign attribution, add a maintained deep-link platform or build those layers separately before replacing every published URL.
This guide turns that answer into a migration plan for mobile developers, product owners, and growth teams. It assumes the service has already shut down, so the goal is recovery and durable replacement—not a last-minute sunset checklist.
Deep link Firebase shutdown: what stopped working
Firebase Dynamic Links shut down on August 25, 2025. Google's Dynamic Links deprecation FAQ says that links served on both page.link subdomains and Firebase-configured custom domains stopped working, clicks return HTTP 404 responses, and the Short Links and Link Stats APIs no longer operate normally.
That creates two distinct problems:
- The public URL is broken. A short
page.linkURL depended on Firebase's redirect service to resolve its stored configuration. You cannot recover that routing logic by parsing the short code after shutdown. - The app integration is obsolete. Old Dynamic Links SDK calls may now return errors or empty data. Even if the app does not crash, a silent empty result can send users to the wrong screen and erase campaign context.
The shutdown did not remove Firebase as a whole. Authentication, Analytics, Cloud Messaging, Hosting, and other Firebase products remain separate. However, mobile email-link authentication and certain out-of-band email actions required updated Authentication SDKs and a new hosting flow; Google's FAQ specifically warns that old app versions can lose those actions.
The practical lesson is to audit by capability, not by dependency name. A codebase search for the Firebase Dynamic Links package finds SDK calls, but it will not find a QR code on packaging, a link inside a lifecycle email, a URL stored in a database, or a campaign template owned by an agency.
Treat legacy links as an incident, not a redirect task
A common response is to put a server redirect in front of the old URL. That works only when you control the hostname and know the destination. Google does not let you transfer an automatically provisioned page.link domain, so there is nowhere for your redirect rule to run on those URLs.
If a dead URL is printed, cached, or embedded in content you cannot edit, record it as an unrecoverable entry point and fix the nearest asset you do control. For a custom domain, confirm DNS ownership and hosting behavior before promising continuity; domain reuse, association files, certificates, and existing path rules all have to coexist.
Build the migration inventory before choosing a replacement
The first deliverable is not an SDK branch. It is a canonical inventory that tells engineering and marketing which journeys exist and which capabilities each journey needs.
Google's Dynamic Links metadata export guide describes a Google Takeout export that produces one CSV per domain. Its fields include the short link, underlying deep link, Android and iOS identifiers, fallback URLs, minimum versions, social metadata, UTM values, link name, and creation timestamp. That export is the best historical source if your team created links in the Firebase console, SDKs, or REST API and retained the file before metadata was purged.
Because you may be working after shutdown, add other sources:
- Search source repositories for
page.link,dynamicLinkDomain,setLongLink,buildShortDynamicLink, and Dynamic Links SDK imports. - Export URLs from email, push, SMS, paid media, social scheduling, referral, QR, and affiliate tools.
- Query application databases for invite codes, share URLs, campaign templates, and saved link objects.
- Review support tickets and analytics events for failed open, fallback, invite, and referral journeys.
- Ask channel owners for offline placements such as packaging, posters, receipts, and event material.
Store one row per link pattern or campaign family. Avoid creating a million-row spreadsheet when the links differ only by a referral token; capture the template and the source of its variable data.
| Inventory field | Why it matters | Example |
|---|---|---|
| Old URL or pattern | Locates every placement to replace | https://example.page.link/invite/* |
| Deep-link destination | Defines the in-app route contract | /invite/{code} |
| iOS and Android app IDs | Maps the journey to the correct apps | Bundle ID and package name |
| Installed behavior | Defines Universal Link/App Link routing | Open the invite acceptance screen |
| Uninstalled behavior | Reveals whether deferred linking is required | Store, then restore the invite code |
| Web fallback | Prevents a dead end on desktop or unsupported devices | Web invitation page |
| Parameters | Preserves campaign and product context | invite_id, utm_campaign |
| Creation method | Tells you what generator must change | App SDK, REST API, dashboard, manual |
| Owner and placement | Makes rollout accountable | CRM team, welcome-email template |
| Priority | Puts revenue and authentication flows first | Critical, high, normal |
Separate the link contract from the Firebase parameter names
Do not copy a legacy URL string and call that the specification. Write a provider-neutral contract such as: “When an invited user opens this HTTPS URL, open /invite/{code} if installed; otherwise route to the correct store, then restore invite_id on first open; on desktop, show the web invitation.”
Then map old parameters into that contract. Common Firebase fields include link for the deep destination, apn for the Android package, ibi and isi for the iOS bundle and App Store IDs, afl/ifl/ofl for platform fallbacks, st/sd/si for social preview metadata, and UTM parameters for campaign context. Keep unknown custom parameters rather than dropping them; the app router or analytics layer may still depend on them.
Choose a deep link Firebase replacement architecture
There is no single native API that replaces the full Firebase Dynamic Links feature set. Google's App Links and Universal Links migration guide makes the boundary explicit: native links can open installed apps in context, but by themselves they do not reproduce one-click store routing, post-install journey continuation, short-link creation, or Dynamic Links analytics.
Choose an architecture based on the inventory, not on the shortest setup tutorial.
| Replacement path | Best fit | What you operate | Important gap |
|---|---|---|---|
| Native Universal Links + App Links | Content links where web fallback is acceptable | Domain, association files, app routing, web pages | No complete cross-platform deferred or attribution layer by itself |
| Deep-link and attribution platform | Campaigns, referrals, install-to-content journeys, measurement | SDK integration, routing rules, governance | Vendor cost and migration work |
| Custom redirect and link service | Teams with narrow requirements and platform expertise | Resolver, storage, signing, fallbacks, observability, abuse controls | High ongoing reliability and privacy burden |
| Hybrid | Product links are native; campaigns use managed deferred links | Two clearly documented link classes | More governance; teams must know which link type to create |
Native links are a strong foundation regardless of the option. Android App Links and iOS Universal Links are ordinary HTTPS URLs with a verified association between your domain and app. They reduce interception risk and give users without the app a web destination. They are not, however, an automatic post-install handoff mechanism.
For many teams, the decisive question is simple: must a first-time installer arrive at a specific screen with campaign or referral context? If yes, test deferred deep linking as a first-class requirement. Do not infer support from a feature called “deep links,” because direct and deferred behavior are different journeys.
Execute the deep link Firebase migration in seven steps
The order matters. If you publish new links before the apps understand them, installed users fall back to the browser. If you remove the old handler before adoption is high enough, older app versions lose the journey. Build the replacement, validate it, release it, and only then change every placement.
1. Freeze old link creation and define ownership
Disable Dynamic Links generation in backend jobs, mobile share flows, internal dashboards, and marketing automation. Return an actionable error during development rather than quietly emitting another dead URL.
Assign one technical owner for routing, one channel owner for placement replacement, and one decision maker for capability tradeoffs. The migration inventory should include a status such as discovered, mapped, implemented, tested, replaced, or unrecoverable. That shared vocabulary prevents “the SDK is done” from being mistaken for “the migration is done.”
2. Choose a domain you control
Use a branded HTTPS domain or subdomain that the company controls independently of a link vendor. Keep ownership, DNS access, TLS renewal, and domain documentation with the organization.
Plan the URL namespace before coding. Stable, readable routes such as /product/{id}, /invite/{code}, and /campaign/{slug} are easier to validate and migrate than opaque application-specific payloads. Decide which paths open the app, which always remain on the web, and which require a server-side resolver.
Avoid a blanket rule that sends every path to the app. Account pages, legal pages, support content, and authentication callbacks may need explicit exclusions. Also define what happens when an entity was deleted, a token expired, or the installed app version does not support the route.
3. Configure verified Android App Links
Add HTTPS intent filters with android:autoVerify="true" for the approved hosts and broad path scope your app can safely route. Host assetlinks.json at:
https://links.example.com/.well-known/assetlinks.jsonAndroid's website association documentation requires HTTPS, application/json, and no 301 or 302 redirect. The file identifies your package and SHA-256 signing certificate fingerprints. If you use Play App Signing, obtain the fingerprint used for distributed releases from Play Console rather than assuming your local keystore fingerprint matches.
Keep routing rules defensive. Parse the incoming URI, allow known hosts and paths, validate parameter formats, and route unknown or invalid values to a safe screen. On Android 15 and later, Dynamic App Links can refine path, fragment, and query rules from assetlinks.json, but server-side rules cannot expand beyond the manifest's declared scope.
4. Configure iOS Universal Links
Add the Associated Domains capability to the correct Xcode target and include an entry such as:
applinks:links.example.comServe an apple-app-site-association file without a file extension at:
https://links.example.com/.well-known/apple-app-site-associationApple's associated domains documentation requires HTTPS with a valid certificate and no redirects. Each subdomain needs its own entitlement entry and association file. The app identifiers and allowed URL components in the file must match the app and route plan.
Handle the incoming NSUserActivity, validate the URL, and pass a normalized route object into the same navigation layer used by notifications and internal app actions. Apple's Universal Links guidance also recommends treating incoming parameters as untrusted input; a link should never directly authorize a sensitive action.
5. Rebuild routing, fallbacks, and deferred behavior
Create a routing matrix before recreating individual links:
| State | iOS | Android | Desktop/web |
|---|---|---|---|
| App installed | Universal Link to target screen | App Link to target screen | Web destination |
| App not installed | Web fallback, Smart App Banner, store, or managed deferred flow | Web/store fallback or managed deferred flow | Web destination |
| Unsupported app version | Safe update prompt or web fallback | Safe update prompt or web fallback | Web destination |
| Invalid/expired target | Helpful in-app error or home | Helpful in-app error or home | Helpful web error |
If Android deferred context is implemented in-house, the Google Play Install Referrer API can return referral content and click/install timestamps from Google Play. That is one platform-specific input, not a complete cross-platform deep-link product. Your design still needs secure token storage, expiry, idempotent redemption, iOS behavior, consent-aware measurement, and handling for non-Play distribution.
If the inventory shows many referral, paid campaign, or install-to-content journeys, a maintained platform is usually the lower-risk choice. Deeplinkly provides branded domains, deferred deep linking, install attribution, and campaign analytics; its free Firebase Dynamic Links migration checker can decode retained long-form Firebase URLs and map their routing fields before you recreate them. Use the Firebase Dynamic Links alternative guide to compare the integration path against your inventory rather than selecting on link creation alone.
6. Replace generators and published placements
Update every link-producing system identified in the inventory:
- Mobile SDK code used for sharing, referrals, and invitations
- Backend REST calls and scheduled jobs
- Marketing dashboards, campaign templates, and CSV generators
- Email, push, SMS, social, affiliate, and paid media templates
- QR code source files and offline print workflows
- Documentation, support macros, website content, and app-store copy
Preserve intentional aliases where users see or type them. Do not preserve opaque short codes merely for cosmetic similarity; map each old route to a stable new destination and record the relationship in a migration table.
When you control the old custom domain, use explicit path redirects only after the new association files and app builds are live. Do not redirect /.well-known/assetlinks.json or /.well-known/apple-app-site-association, and test that your CDN or framework does not add a trailing-slash redirect to either file.
7. Release in phases and remove obsolete code
Ship the app changes before changing high-traffic links. Use a staged rollout where practical, watch app adoption, and test both the new and previous supported versions. For critical journeys, keep compatible handlers until enough users have updated or provide a web recovery path.
Once new links are stable:
- Remove Firebase Dynamic Links SDK imports, initialization, entitlements, intent filters, and callbacks that are no longer used.
- Remove obsolete API credentials, service accounts, build plugins, and backend jobs.
- Update runbooks so incident responders know which system owns resolution and attribution.
- Set monitors for resolver errors, web fallback rates, app-open success, missing route parameters, and post-install completion.
- Retain the inventory and parameter mapping as an audit artifact.
Do not remove unrelated Firebase SDKs simply because their package name starts with Firebase. Confirm each dependency's purpose and owner.
Preserve attribution without coupling it to navigation
Firebase Dynamic Links often carried both a product route and marketing parameters. Rebuilding that URL is an opportunity to separate concerns: navigation decides where the user goes; attribution records how the user arrived.
Define a normalized payload with fields such as route, campaign_id, channel, creative_id, referral_token, and clicked_at. Validate and log the payload at the resolver, then pass only the fields required by the app. Keep sensitive user data out of URLs, because links travel through browsers, logs, messages, screenshots, and analytics systems.
Use stable campaign identifiers instead of relying only on display names or UTM strings. Decide how a click is deduplicated, when an attribution window expires, and which source wins when the same person clicks multiple campaigns. Those are measurement policies, not routing details.
For privacy, document which identifiers are collected, why they are needed, how long they are retained, and whether consent gates apply. A migration should not recreate accidental data collection simply because an old Firebase link contained a parameter.
Test the replacement as a journey, not a URL
A browser returning 200 proves almost nothing about mobile routing. Test the full journey across app state, device, app version, source application, and destination.
Minimum release coverage should include:
- Current iOS with the app installed, not installed, freshly installed, and recently updated
- Current Android plus the oldest supported Android version in the same states
- Safari, Chrome, Messages, Mail, major social in-app browsers, QR scanning, and copied/pasted URLs
- Valid, expired, malformed, encoded, and missing parameters
- Web fallback on mobile and desktop
- Store routing and first-open restoration where deferred deep linking is promised
- Existing users on the previous app release
- Authentication email actions if the app uses them
On Android, verify the domain association rather than trusting a manual chooser selection. The official App Links troubleshooting guide highlights common failures including incorrect signing fingerprints, redirected association files, and mismatched hosts. On iOS, remember that association-file changes may be cached through Apple's delivery infrastructure, so test against release-like hosting and allow for propagation behavior documented by Apple.
Record an expected outcome for every test cell. Capture the URL, source app, device/OS, install state, app version, final screen, preserved parameters, fallback, and analytics events. A reproducible matrix is much more useful than a screenshot saying “works on my phone.”
Migration acceptance criteria
Call the migration complete only when:
- Every critical inventory row has a replacement or documented retirement decision.
- New apps handle valid links without an unnecessary chooser or browser hop.
- Uninstalled-user behavior matches the written contract on both platforms.
- Deferred context survives install for journeys that require it.
- Web and error fallbacks are useful, not generic home pages.
- Campaign and referral parameters arrive once, with defined attribution rules.
- Firebase Dynamic Links creation code and credentials are gone.
- Monitoring can detect route, resolver, and post-install failures.
Common Firebase migration failures
Replacing the SDK but not the links. The new app can handle your branded domain, but emails and QR codes still point to page.link. Track placement replacement separately from app implementation.
Assuming native links are deferred links. Universal Links and App Links open installed apps and fall back to the web when the app is absent. They do not automatically restore arbitrary campaign context after an app-store install.
Using the wrong Android certificate fingerprint. Debug, local release, and Play App Signing certificates can differ. Publish every legitimate fingerprint required by your supported builds, and test the store-distributed app.
Redirecting association files. Both platform verification files must be directly accessible over HTTPS. CDN normalization, locale middleware, authentication, or trailing-slash rules can silently break verification.
Dropping custom parameters. A parameter that looks unused to the migration script may drive a referral reward, content variant, or analytics join. Trace consumers before removing it.
Ignoring old app versions. A new resolver can emit routes that an older app does not understand. Version your route contract or provide a safe fallback.
Forgetting Firebase Authentication flows. Dynamic Links deprecation affected some mobile email-link and out-of-band action flows. Follow the current platform-specific Authentication guidance linked from the Firebase deprecation FAQ, and test older supported app versions explicitly.
Frequently asked questions
Is Firebase Dynamic Links still working?
No. Firebase Dynamic Links shut down on August 25, 2025. Google states that hosted links stopped working, clicks return HTTP 404 responses, and the Dynamic Links APIs are no longer available for normal use.
What should replace Firebase Dynamic Links?
Use iOS Universal Links and Android App Links for verified links into an installed app. Add a deep-link platform or a carefully designed custom service when you also need deferred deep linking, cross-platform store routing, short links, campaign attribution, or managed analytics.
Can I recover an old page.link short link after shutdown?
Not from the short code alone. Its destination and routing rules lived on Firebase's service. Recover the original long-form URL, a historical Google Takeout export, source code, campaign configuration, analytics data, or another system that stored the resolved destination.
Do Universal Links and App Links support deferred deep linking?
Not by themselves. They open installed apps through verified HTTPS associations and otherwise fall back to a website. Post-install context requires an additional platform-aware mechanism, such as a managed deferred deep-link service or a custom design with explicit Android and iOS behavior.
Can I keep my old Firebase custom domain?
Possibly, if your organization owns and controls the domain and can reconfigure its DNS and hosting. You cannot transfer a Firebase-provisioned page.link domain. Before reusing a custom domain, check current redirects, TLS, association files, cached links, and whether any unrelated Firebase Hosting routes depend on it.
Does the shutdown affect Firebase email-link authentication?
The Authentication product continues, but mobile email-link and other out-of-band actions required migration to updated SDK behavior. Follow the current Firebase Authentication instructions for iOS and Android and test old app versions, because Google's FAQ warns that older versions may no longer complete those actions.
When can I remove the Firebase Dynamic Links SDK?
Remove it after the replacement app handlers are released, critical placements use the new URLs, required legacy behavior is retired, and monitoring shows the new journeys are stable. Remove only the Dynamic Links integration—not unrelated Firebase products your app still uses.
Finish with a capability-by-capability decision
A durable migration does not ask, “Which SDK looks most like Firebase?” It asks which journeys need installed-app routing, web fallback, store routing, post-install continuation, attribution, short links, and analytics—and assigns a tested owner to each capability.
Start by building the inventory, marking the critical flows, and testing one representative invitation or campaign end to end. Then use the free migration checker to decode any retained long-form Firebase URL, validate the mapping, and roll the same contract through the rest of your links.