Firebase Dynamic Links shutdown forces deferred deep-link migration

Firebase Dynamic Links is documented as reaching an end-of-service cutoff rather than a gradual API version deprecation, which removes the resolution layer that previously survived app installs. Teams relying on deferred deep linking or link-based attribution face a compatibility boundary where the short page.link host stops redirecting and the console and API surface are withdrawn. Native App Links and Associated Domains remain functional for users who already have the app installed, but they do not restore post-install routing.

The unresolved decision is architectural: implement a self-hosted redirect endpoint that records intended destinations and passes them to the app on first run, adopt a third-party deferred deep-link provider, or drop post-install routing and accept that old links fail for new installs. Existing short links embedded in emails, ads, QR codes, and past shares cannot be rewritten retroactively, so link rot in uncontrolled material is a persistent risk. Any replacement that passes install identifiers also changes the project's privacy and data-processing posture.

Because deprecation dates and console availability move over time, what migration scope is safest for a project that still depends on deferred deep linking? Should the replacement preserve the same user-visible URL structure, or is a controlled domain change acceptable? How should teams confirm that native App Links and Universal Links are fully independent before retiring the Dynamic Links SDK?