If you're still using Firebase Dynamic Links (FDL) for install/deep linking and deferred marketing links, the longer you leave it, the more business impact you're going to have in the short-term. FDL is deprecated by Google, and the longer it remains in use, the more invite links will break, referral credits won't attribute, and app installs will erroneously fallback to a default App Store listing instead of the screen you wanted them to see.
This isn't an article to scare you into migrating. It's a migration survival guide, which walks through this checklist in detail to minimize breakage.
Why this actually matters (not just SEO clickbait)
Firebase Dynamic Links encapsulates three core capabilities that most marketing teams would expect out-of-the-box in a linking solution:
- Deferred deep linking infrastructure, utilizing match tokens and referral data attribution to route users to specific in-app destinations
- Cross-platform compatibility handling, to ensure links behave consistently whether resolved via iOS, Android, or desktop clients
- Intelligent fallback behavior for resolving links when users install the app from a link click
None of these capabilities magically persist if/when FDL dies, and they tend to require significant operational overhead to replicate. Referral links break, marketing campaigns lose attribution, and customer support sees more fallout unless you've instrumented every step of this process, which isn't obvious on an FDL dashboard "why did signups drop."
Migration checklist
1. Know where all your FDL links live
Before making any code changes, compile a comprehensive list of all surfaces that contain links utilizing FDL's .page.link domain. This may include:
- Transactional or marketing emails (welcome, referral, promo, etc)
- In-app notifications or share destinations
- SMS messaging or other short-linking services
- Ad creatives (particularly if leveraging UTM parameters)
- QR codes or hard-coded links in printed materials
Ideally, your list should be comprehensive before you begin migrating these links to another service.
2. Document what all your links do
For every link surface type you identify in step one, document the linking behavior. At a minimum, this should include:
- What deep link destination it resolves to within the app
- What fallback store listing resolves if the user doesn't install the app
- If it contains any deferred payload (e.g. which friend referred them)
- If it requires any platform-specific treatment (iOS vs Android)
You'll need this data regardless of what service you migrate to, as it serves as documentation for whichever solution you choose
3. Set up domain and app verification with the new service
Universal Links (iOS) and App Links (Android) require domain-level app verification, which requires hosting specialized JSON files (`apple-app-site-association` and assetlinks.json, respectively) on your domain. If you intend to transition from FDL's shared catch-all domain to a branded domain for your links (highly recommended for security and click-through improvements), domain verification must succeed before any links will resolve correctly.
This step may also require additional time if you're transitioning from FDL's free tier to a paid enterprise plan with the same provider.
4. Rebuild deferred deep linking capabilities
You'll need some method to handle deferred deep linking for users who clicked a link but didn't yet have the app installed when they clicked it. Implementing this capability requires:
- Matching the clicked link to the app install, either by token or some other fingerprinting mechanism
- Handling Play Store referrer data on Android
- Extracting App Store campaign tokens from iOS (or falling back to a universal clipboard or link-scheme parsing method)
It's particularly important to test your implementation for the "not installed → install → first open" install scenario, not just the install-once-open scenario.
5. Migrate in waves, starting with the lowest risk link types
Migrate your least important link type first (internal links used exclusively by your QA team, perhaps), verifying correct resolution behavior across iOS and Android. Then move on to more critical link types in subsequent stages: referral program links, then marketing emails, and finally paid advertising links last (since they're often the most complex to migrate retroactively once they've launched).
6. Continue monitoring and using both services in parallel
If you've already distributed any links that utilize FDL, make sure you have a fallback or redirect in place so that they don't simply become dead links at the moment of switch-over. A dead link is far more damaging to your brand than an incorrectly resolving one, and it's always wise to keep both services running in parallel for at least a brief period to be absolutely certain.
7. Verify analytics dashboards and linking behavior after migration
Make sure whichever service you migrate to can provide similar analytics dashboards, so you can monitor campaign performance in parallel. It's critical to ensure that analytics aren't being lost or misreported during migration, and that campaign-specific, referral, or deep linking traffic successfully resolves to the correct destination(s).
8. Kill the old service only after you've verified everything else is working
Only once you're confident that migrated links are properly resolving and analytics are being reported as expected should you consider killing the old FDL domain.
What to look for in a replacement
Any FDL replacement should be able to handle whatever capabilities Firebase offered while reducing the total number of tools you have to juggle, particularly if you're already using separate services for analytics or ad tracking:
- Built-in iOS Universal Links and Android App Links verification
- Deferred deep linking behavior utilizing match tokens or store install-referrer data
- Cross-platform smart routing rules to avoid having to code this behavior yourself
- Campaign attribution and analytics tracking, including click-through, install, and open events
- SDKs for the development frameworks your business utilizes (Flutter, React Native, Unity, Web, etc)
The last bullet is more important than it may seem. Many FDL competitors are primarily attribution-focused tools, which means their linking capabilities may suffer from being an afterthought in terms of development and maintenance.
How WilderLinks fits in
WilderLinks is a linking platform built specifically for teams looking for a robust, privacy-focused alternative to Firebase Dynamic Links, with a particular focus on security, analytics, and ease of use. Some specific features that would help with an FDL migration include:
- Branded domains for all short links, with Universal Links and App Links verification handled automatically
- Deferred linking via match tokens, with analytics for every stage of the campaign lifecycle
- Click-through analytics, along with install, open, and funnel tracking
- SDKs available for Flutter, React Native, native mobile, web, and Unity so you don't have to write linking or routing code for every platform individually
WilderLinks is currently in public beta and available for use at no cost during the early adopter period, and we're happy to help anyone who needs assistance walking through this very process. If you'd like someone to review your existing Firebase Dynamic Links, please feel free to connect with us! (https://www.wilderlinks.space/contact) or [sign up for a sandbox workspace](https://www.wilderlinks.space/register) and ask us for help. We're actively helping multiple companies through this same FDL migration checklist and would be happy to assist you.
For an overview of the full capabilities of WilderLinks, see our [comparison of Firebase Dynamic Links alternatives](https://www.wilderlinks.space/firebase-dynamic-links-alternative) or [check out the documentation](https://www.wilderlinks.space/docs).
