How to move from Firebase Dynamic Links to Ferry.

Start with the links that still matter.

Do not begin by recreating every historical short URL. Begin with the links that still have distribution or business value. Old QR codes, packaging, referral programs, lifecycle emails, app invites, and paid campaigns deserve attention before a launch announcement from three years ago.

If you have a Firebase export, normalize it into one working sheet with:

• the old short URL and suffix;
• the deep link or in-app destination;
• iOS, Android, and desktop fallbacks;
• campaign source, medium, and name;
• where the link is still published;
• an owner and migration status.

Without an export, search campaign tools, email templates, QR source files, backend records, app configuration, support macros, and analytics history. Put the recovered links into the same sheet. This inventory becomes the cutover checklist.

Map the old model to Ferry.

The concepts are close, but the payload should not be treated as a pile of redirect parameters. In Ferry, a project represents one app. A hostname belongs to one project, and each link carries structured data that your app reads.

Use payload.data as the contract between a link and your app. A link to a summer offer might carry { "screen": "offer", "campaign": "summer" }. Your app owns the final navigation logic, so it can evolve without baking fragile routes into every campaign URL.

Rebuild the domain and links.

Create a Ferry project with your iOS bundle ID, Android package name, store destinations, and desktop fallback. Then choose the hostname your links will use.

Create permanent campaign links with a server-side sk_ key or in the dashboard. Never put that key in an app. Your mobile app uses a project-scoped pk_ key for resolve, match, and restricted event reporting.

{
  "projectId": "YOUR_PROJECT_ID",
  "domainId": "YOUR_DOMAIN_ID",
  "slug": "summer",
  "payload": {
    "data": {
      "screen": "offer",
      "campaign": "summer"
    }
  },
  "campaign": {
    "source": "newsletter",
    "medium": "email",
    "name": "summer"
  }
}

Replace the app integration in two paths.

Deep linking has two moments, and both need to be tested. The direct path opens an installed app. The deferred path sends a user to the store, then restores the link payload on first launch after install.

Ferry returns a match method and confidence with the payload. Deterministic signals are preferred. If a fingerprint could refer to more than one click, Ferry returns no match instead of guessing.

{
  "matched": true,
  "method": "install_referrer",
  "confidence": { "kind": "deterministic" },
  "clickId": "clk_3Qm8xR2v",
  "payload": {
    "data": { "screen": "offer", "campaign": "summer" }
  }
}

Keep the returned clickId. Send it when the user signs up or makes a purchase so the dashboard can connect the outcome to the link and campaign, not just count the open.

Cut over only after the full journey passes.

Use a staging hostname or an unpublished slug while the app change is under review. Test real devices where possible. Browsers, in-app web views, stores, and operating systems do not all behave like a simulator.

For a custom domain, lower DNS TTL before the cutover if your provider allows it. Recreate the important slugs, verify the well-known files, ship the app update, and only then point the hostname at Ferry. Keep a rollback note until traffic and attribution look normal.

For old page.link URLs, there is no DNS switch to make. Replace them at every touchpoint you control, publish app and support messaging for the rest, and use campaign reports to find high-value sources that still send traffic to dead links.