How to move off Firebase Dynamic Links after the shutdown

What was Firebase Dynamic Links?

Firebase Dynamic Links was Google's deep linking service that sent users to the right app screen or store page from a single link, including after a fresh install, and it shut down on 25 August 2025.

Dynamic link: a short link that behaves differently by platform and install state, opening the app if installed, or routing to the store and then the intended screen if not.

If your app, emails or printed material still carry these links, users who tap them are reaching an error page today.

What happens to Firebase Dynamic Links now?

Every Firebase Dynamic Link clicked after the shutdown returns an HTTP 404 to the user. Google rolled out error responses gradually from 25 August 2025, reaching 100% once the sunset date passed.

The rest of the service is gone too, according to Google's FAQ:

• page.link domains: no longer available once the service shut down. Links on these domains cannot be revived.
• APIs: requests to the Short Links API and Link Stats API return a 400 or 403 status.
• Metadata: domain and link metadata were marked for deletion on 25 August 2025. URL prefix domains are deleted automatically after that date.

The mmppricewatch record of the Firebase Dynamic Links shutdown logs the timeline.

Can you still export your old link data?

Google's export path is Google Takeout, not a REST API (export guide). Whether a Takeout export still works now that the deletion date has passed is not published, so try it before relying on it.

What the guide says about the export:

• You must be signed in with a Google Account that has owner permissions on the Firebase project.
• Links created with the Firebase SDKs or REST API are included only if you choose them in the Takeout "Advanced" options. Console links alone are not the full picture.
• Data comes as CSV files, one per domain.
• Columns include the short link, deep link, Android and iOS fallbacks, app identifiers, social meta tags, UTM parameters, link name and creation time.
• An export can take up to a day.

If the export fails, rebuild the list from your own sources: ad platforms, email templates, CMS content, QR code artwork and creator briefs. The deep link migration guide has a full inventory list.

Google's replacement options

Google's FAQ gives three paths, depending on what you used Dynamic Links for.

1. App Links and Universal Links

Google recommends these if you only need to deep link into an app that is already installed. Its guide uses a domain you own, for example one on Firebase Hosting, with assetlinks.json and apple-app-site-association files under /.well-known, and new links that reuse your old deep link paths.

Google's own guide lists what they do not do:

• They do not route users to the correct app store. Google suggests Smart App Banners on iOS.
• They do not continue the user's journey after first download and open, so there is no deferred deep linking.
• They do not provide click analytics.
• They do not create short links.

2. A third-party deep linking provider

For full feature parity, Google points to third-party providers. Its FAQ names Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava and Singular, and notes they "have not been vetted by Google".

3. No replacement

If you no longer need the links, Google says to review and export link metadata, delete URL prefixes in the Firebase console and remove the SDK.

Firebase Authentication email links

This one is easy to miss. If your app used Dynamic Links for Firebase Authentication email links, password reset or email verification, Google says you must upgrade to the latest Firebase Authentication SDKs. Check sign-in flows on both platforms, not only marketing links.

What vendor migration guides add

Two providers publish specific Firebase migration guides:

• AppsFlyer publishes a guide to migrate from Firebase Dynamic Links to OneLink.
• Branch says links on the default page.link domain must be replaced. A custom Firebase domain can be kept by recreating links with the same alias, with brief downtime when the CNAME switches. Branch also says its SDK can run alongside the Firebase SDK, but on iOS this "will cause issues unless you disable method swizzling".

The custom domain point matters most. If your Dynamic Links used your own domain rather than page.link, old printed links can work again once that domain points at a new provider and the paths are recreated.

A migration order that works

1. Find every old link: export via Takeout if it works, otherwise rebuild the list from your own channels.
2. Separate page.link links from custom domain links. page.link links must be replaced; custom domain links can be revived.
3. Choose the replacement: App Links and Universal Links if installed-app routing is enough, a provider if you need store routing, deferred deep links, analytics or short links.
4. Ship an app update with the new domain in Associated Domains and intent filters, and the upgraded Firebase Auth SDK if needed.
5. Remove the Firebase Dynamic Links SDK once nothing calls it.
6. Replace links you control and ask partners to update theirs.

If you also use an MMP and are weighing whether to merge links and attribution in one tool, the destination guide compares options, and the Firebase Dynamic Links exit page has the short version. The planner can add a link track to your plan.

Linkrunner, not on Google's list, also publishes a Firebase Dynamic Links migration page.