Firebase Dynamic Links migration: a practical checklist for teams moving fast
A clean migration is usually less about rewriting everything and more about rebuilding the right routes in the right order. Start with your core campaigns, validate the new domain behavior, and keep rollout steps simple.
What to keep in scope
The goal is to preserve working routing behavior, fallbacks, and campaign links while removing the operational overhead that comes with maintaining link infrastructure yourself. Treat this as a controlled migration, not a full rebuild of your app stack.
A safe migration focuses on
- Your highest-traffic existing links and campaign destinations.
- Universal link and app link file validation before launch.
- Fallback routing for users who do not have the app installed.
- Click-log review after rollout so you can confirm traffic is flowing.
What changes during migration (and what should not)
| Area | Expected change | Must remain stable |
|---|---|---|
| Link infrastructure | Association file hosting and route management move to your managed setup. | User-facing destination intent for each campaign link. |
| Operations | Less DIY maintenance for AASA/assetlinks and hosted fallbacks. | Clear ownership for QA, release signoff, and incident handling. |
| Campaign links | Critical routes are recreated in phases. | Tracking tags, destination paths, and fallback rules. |
| Validation workflow | Prelaunch checks rely on domain validation and route QA. | Every production cutover has a go/no-go checklist. |
The migration checklist
1. Audit the links you still use
- List the links used in paid campaigns, lifecycle flows, app onboarding, QR codes, and owned channels.
- Prioritize links that still drive meaningful traffic.
- Document the intended app path and the non-app fallback for each route.
2. Rebuild the critical routes first
- Start with your highest-value links instead of migrating everything at once.
- Recreate the destination, path, and fallback behavior in the new setup.
- Keep the first rollout small enough to test thoroughly.
3. Validate the domain configuration
- Confirm the AASA and assetlinks.json files are reachable from the live domain.
- Check for redirects, response-header issues, and malformed JSON.
- Re-run validation after any DNS, CDN, or reverse-proxy change.
4. Roll out and watch the logs
- Switch the campaign links after the domain and fallbacks are verified.
- Review click counts and recent access logs after launch.
- Resolve any mismatch before migrating lower-priority links.
Link inventory template (copy this before cutover)
| Field | What to capture |
|---|---|
| Legacy link slug/URL | The existing Firebase Dynamic Link currently in use. |
| Channel | Ads, email, push, QR, web CTA, influencer, lifecycle, etc. |
| Target app path | The in-app destination expected after open. |
| Fallback destination | App Store, Play Store, web page, or onboarding page. |
| UTM behavior | Which query params must be preserved for reporting. |
| Priority tier | P0 (critical), P1 (high), P2 (later migration). |
| Owner | Team or person responsible for recreating and QA-testing the route. |
This avoids the most common migration failure: recreating links without preserving fallback intent or campaign parameter behavior.
What usually causes migration friction
- Teams try to migrate every old route at the same time.
- Association files are updated but not re-validated from the public domain.
- Fallback destinations are not checked for users without the app.
- Old campaign links are swapped before the new route is QA-tested.
- Traffic is moved without reviewing click logs afterward.
Suggested phased rollout timeline
Phase 1: Inventory and rebuild
- Audit active links and tag by business impact.
- Recreate critical routes first.
- Define fallback behavior for each route.
Phase 2: Validation and QA
- Validate AASA and assetlinks on the production host.
- Test iOS/Android open flows and no-app fallback paths.
- Confirm core campaign UTM behavior.
Phase 3: Cutover and monitoring
- Switch high-priority traffic first.
- Monitor click logs and route outcomes after launch.
- Migrate lower-priority links after the first batch is stable.
Cutover QA matrix
| Scenario | Expected result | Evidence to capture |
|---|---|---|
| iOS user with app installed | Universal link opens the intended in-app route. | QA screenshot/video + confirmation from app team. |
| Android user with app installed | App Link opens the intended in-app route. | QA screenshot/video + route parity with iOS. |
| User without app installed | Fallback goes to the correct store or web path. | Store/fallback destination verified on both platforms. |
| Post-launch traffic sample | Click logs show expected destinations and platform mix. | No unexplained spike in failed or misrouted clicks. |
A low-risk rollout plan
- Inventory your active Firebase Dynamic Links.
- Recreate the most important routes in the new setup.
- Validate AASA and assetlinks.json before switching traffic.
- QA the app path and fallback on iOS, Android, and desktop.
- Move the next group of links only after the first batch is stable.
Helpful resources
- Universal Links Validator - check the domain before cutover.
- Smart links overview - understand routing, fallbacks, and short-link behavior.
- Developer overview - review the app and domain configuration steps.
- Deferred deep linking guide - align install-time routing and first-open behavior after migration.
Migrate the routes that matter first
A phased migration is usually faster, safer, and easier to QA. Rebuild your critical links first, validate the infrastructure, and let usage data guide the rest of the rollout.
Firebase Dynamic Links migration FAQ
What should I audit before migrating from Firebase Dynamic Links?
Start by inventorying the links you still use in campaigns, notifications, emails, QR codes, and app flows. Group them by destination and fallback behavior so you can rebuild the critical routes first.
Do I need to move every link at once?
No. A phased migration is usually safer. Recreate your highest-value links first, validate the domain and association files, then move lower-priority campaigns after your core flows are stable.
How do I reduce launch risk during migration?
Validate AASA and assetlinks.json before switching traffic, test fallbacks on each platform, and review click logs after rollout. This gives you a simpler way to confirm the new links are resolving correctly.