Skip to main content
DecTog

Migrating Off Firebase Dynamic Links: The Post-Shutdown Guide

Firebase Dynamic Links (FDL) is gone. The service shut down on August 25, 2025, and every link it served — on page.link subdomains and on customers' custom domains alike — now returns an error to whoever taps it. If your app sent Dynamic Links in emails, printed them in QR codes, or embedded them in campaigns, those URLs are broken until you stand up a replacement.

This guide is the migration playbook: what actually happened, what FDL gave you, and a concrete path to rebuild your link infrastructure on ground you control.

What happened, and when

The timeline, for the record:

  • May 2023 — Google announced FDL's deprecation, giving the ecosystem a two-year window to move.
  • August 25, 2025 — the service shut down. Links began failing, with error rates ramping to 100%, and Firebase marked link and domain metadata for deletion. The Short Links and Analytics APIs went with it.
  • Today — old FDL URLs are dead weight in your emails, QR codes, and ads. Every tap is a lost user.

The lesson many teams took from this: link infrastructure on a domain someone else controls — and can switch off — is a liability. Whatever replaces FDL, run it on your own domain.

What FDL gave you (and what you're replacing)

Dynamic Links bundled four things into one product, and your replacement needs an answer for each:

  • One short link per target, cross-platform — iOS, Android, and desktop behaved appropriately for each.
  • Deferred deep linking — new users went through the store and still landed on the linked content. (How this works: What is Deferred Deep Linking?)
  • Install attribution — which campaign produced which install.
  • Analytics — clicks, opens, and conversions per link.

Notice that none of these require Firebase. They require link infrastructure — which is exactly what shut down.

Step 1: Audit where your FDL links live

You can't replace what you can't see. If you exported your link inventory from the Firebase console before deletion, start there. If you didn't, reconstruct it from the wild:

  • Sent emails and push notification payloads (templates and automation flows especially — these keep firing for years)
  • QR codes on anything physical: packaging, receipts, flyers, event materials
  • Paid campaigns and their creative
  • Social profiles and influencer content
  • URLs hard-coded in your app or website

Sort the findings into two piles: links on your own custom domain, and links on page.link. The first pile is recoverable — you control the domain's DNS. The second is not; Google's domain will keep 404ing no matter what you do, so those links have to be replaced at the source.

Step 2: Choose your replacement path

Three realistic options:

  • Native-only: App Links + Universal Links on your domain. Free, robust, no third party. But you lose the deferred deep linking, attribution, and analytics layers — you'd be rebuilding those yourself. Fine for apps that only need routing, thin for anyone doing marketing.
  • A mobile measurement partner (Branch, Adjust, AppsFlyer). Full-featured and battle-tested, with pricing and SDK weight to match. Reasonable if attribution at ad-network scale is core to your business.
  • A focused, self-hostable link platform like DecTog. Short links on your domain, the verification files served for you, deferred deep linking, install attribution, and click analytics — without handing your link layer to another party that might sunset it. This is the option this guide walks through.

Step 3: Rebuild the link infrastructure

With DecTog the setup is deliberately short:

  1. Create your app in the dashboard and fill in the platform details — Android package name and iOS bundle ID. DecTog uses these to generate and serve the Android assetlinks.json and iOS apple-app-site-association verification files on your link domain, so App Links and Universal Links verify without you hand-editing JSON.
  2. Connect a link domain. Use a subdomain of your main site (links.yourbrand.com) or your root domain. Because you own it, this infrastructure can't be switched off from under you — the anti-FDL insurance.
  3. Recreate your links — in the dashboard or via the API — with the same destinations your FDL links had. Each link gets a slug, a destination, and optional campaign tags.

Step 4: Replace the SDK surface

FDL's API surface in your app maps almost one-to-one onto any competent replacement. The four jobs to re-wire:

  • Creating links — buildLink() / short link creation becomes a call to your new link service (or links you pre-create in a dashboard).
  • Foreground links — the onLink stream becomes your new SDK's link stream.
  • Cold-start links — getInitialLink() becomes the new SDK's initial-link API.
  • Attribution — where FDL reported the click that led to the install, your replacement's attribution callback does the same job.

Mechanically this is usually an afternoon of work in a Flutter or React Native app: remove the firebase_dynamic_links dependency, add the new one, and re-point four call sites. The tedious part is Step 1's inventory, not the code.

Step 5: Rescue traffic from your old URLs

  • Custom-domain FDL links: point the domain (or a path prefix) at your new link service and issue redirects to the corresponding new links. Traffic keeps flowing; bookmarks and printed QR codes keep working.
  • page.link links: dead by nature. Replace them everywhere you control — email templates, campaign configs, social bios — and re-print any physical QR material when it's next in the production cycle.
  • Watch your app store listing and website footer — FDL URLs have a way of hiding in both.

Step 6: Verify and monitor

Before calling it done, walk the matrix on real devices: iOS and Android, app installed and not, cold start and foreground resume, and a fresh install through the store to confirm deferred routing and attribution. After launch, monitor your new link analytics for a couple of weeks — click volume by source should roughly match what you replaced, and any old-domain 404s should trend to zero.

Migration checklist

  • Inventory of every live FDL URL (custom-domain vs. page.link)
  • Replacement platform chosen, on a domain you own
  • Verification files serving correctly (check both /.well-known/ paths)
  • SDK swapped: link create, foreground, cold-start, attribution
  • Redirects live for custom-domain links; page.link links replaced at source
  • End-to-end test matrix passed; analytics baseline established

DecTog was built for exactly this migration: create an account, register your app, and have your first working link on your own domain in minutes. New to the underlying concepts? Start with What is Deep Linking?