How to Export Your Links and Data From Bitly

Migrating a link library from Bitly to Flyn is mechanically simple, sign up, import CSV, point your CNAME. The thing that makes migrations risky isn't complexity; it's the order of operations. Do the steps in the wrong sequence and you take down every short link on your branded domain for an hour. Do them in the right sequence and nobody notices the change happened. Still comparing platforms first? Our roundup of the best link management tools covers the whole market honestly.

This guide is the order of operations we recommend, refined across thousands of Bitly-to-Flyn migrations. Most are done in well under an hour. The 10-minute estimate in the title refers to active work, most of the wall-clock time is DNS propagation and validation, which run in the background.

What you'll need before kicking off

• Bitly admin access, you need permission to generate the data export and (if applicable) modify custom domain settings
• DNS admin access for your custom domain (if you use one), typically your registrar or DNS provider (Cloudflare, Route 53, Namecheap)
• 30 minutes of focused time, most steps take a minute or two, but you want to be able to respond if something looks off
• A test link or two you can sacrifice if needed, useful for end-to-end validation before flipping production traffic

Things to inventory upfront

Spend five minutes writing down:

• All custom domains you use with Bitly (e.g. links.yourcompany.com, go.yoursite.com)
• Any third-party integrations using Bitly (Zapier, HubSpot, Salesforce, Slack, custom webhook receivers)
• The marketing team's naming conventions for slugs and UTM values, you'll want to recreate any saved defaults
• Hardcoded Bitly URLs in your own product or documentation that need updating post-migration (these are often forgotten)
• The high-traffic links you really, really don't want to break, spot-check these after the cutover

Five minutes. Sign up at flyn.to with an email address, no credit card required for the free tier, which has everything you need to validate the migration before any commitment.

Account configuration that matters early

Inside your fresh dashboard, do these three things before anything else:

• Set your workspace name and timezone. Timezone matters for analytics reports, Asia/Kolkata is the default for new projects but pick your team's working timezone. Bitly's reports default to UTC, so don't expect numbers to match exactly even after migration.
• Invite key teammates. Admin, editor, viewer roles cover most needs (see the link security guide for the RBAC matrix). You don't need everyone in immediately, but anyone who touches links should be invited before you cut over so they can verify their own links post-migration.
• Generate at least one API key. Settings > API Keys > New key. Label it descriptively (ci-bot, migration-bot). You'll use this for any programmatic import work, see the API guide for the full reference.

Plan selection

For the migration itself, the free tier handles the validation phase. Upgrade to Pro before the bulk import, Pro unlocks the CSV importer, custom domains, and password protection, which are the features you almost certainly want on the platform you're moving to. API access is also a Pro feature, so programmatic import needs Pro as well; the CSV importer just makes it faster.

What you don't need yet

Don't add your custom domain or import any links yet, those steps come later in a specific order. The point of Step 1 is just to have a working account ready to receive the imported data.

Log into Bitly and navigate to Settings > Data Export. This is the dashboard's self-service data export tool. Submit a request for your complete link history; Bitly emails a CSV (or .zip of CSVs for large accounts) within a few minutes to a few hours, depending on your account size.

What the Bitly export contains

The CSV has one row per link with columns for:

• Bitlink (the short URL on bit.ly or your branded domain)
• Long URL (the destination)
• Title (display name)
• Created (timestamp)
• Tags (comma-separated)
• Total clicks (a cumulative count, not per-day)
• Custom hashtags if applicable

What's NOT in the export

• Per-day click data, Bitly's CSV gives totals, not the day-by-day series
• Per-click geo, device, referrer data, only available via Bitly's API on Pro+ tiers, often time-windowed
• Webhook configurations, these don't live in the link data; you'll recreate them in Step 9
• UTM defaults or campaign templates, Bitly's UI-level saved settings aren't exported
• Group/team membership, irrelevant since you'll set up roles fresh in Flyn

Optional: pull richer historical data via the Bitly API

If you specifically need per-day click history for your records, the Bitly API's /v4/bitlinks/{bitlink}/clicks endpoint returns time-series data, but you'll need to script the iteration and rate-limit handling. For most teams, the CSV-level totals are enough archival; if you need richer historical detail, do this pull before cancelling your Bitly account.

If you use a custom branded domain with Bitly (e.g. links.yourcompany.com), add it to Flyn now, before importing any links. This sets up the receiving end so when you flip DNS in Step 7, traffic lands cleanly.

Adding the domain

From your Flyn dashboard, Settings > Domains > Add domain. Enter your domain. Flyn displays:

• The CNAME target your domain needs to point to (typically routes.flyn.to or similar, your dashboard will show the exact value)
• A TXT verification record proving you control the domain
• SSL provisioning status (auto-provisioned via Let's Encrypt once DNS is correct)

See the domains doc for the full reference, plus exact records for popular providers (Cloudflare, Route 53, Namecheap, Google Domains).

Add the TXT record now

The TXT verification record can be added without changing your CNAME, it lives at a different host (typically _flyn-verify.yourdomain). Add it through your DNS provider's interface. Flyn's verification check polls every few minutes; the dashboard's status changes from "Pending" to "Verified" once your DNS provider serves the record.

Don't change the CNAME yet

This is the critical sequencing point. You've told Flyn "I'll be hosting this domain on you", but the CNAME still points at Bitly's servers, so every existing short URL continues to redirect through Bitly. Flyn knows your domain is coming; Bitly is still actually serving traffic. Both are true. This is the safe state.

Verifying you've set this up correctly

Run dig CNAME links.yourcompany.com from a terminal (or use a public DNS-lookup tool). It should still resolve to Bitly's servers. Run dig TXT _flyn-verify.yourcompany.com. It should resolve to the verification value you added. Both being true means you're set up for a clean cutover in Step 7.

The CSV importer is the workhorse of any migration. Located in the dashboard at Tools > Bulk Import > From Bitly CSV, it parses the Bitly export, maps fields automatically, surfaces validation errors before the import runs, and creates every link with the same slug it had on Bitly.

The Bitly → Flyn field mapping

Validation runs before the import

The importer flags issues before creating any links. The most common categories:

• Slug conflicts, a slug already exists on the target domain in another Flyn workspace
• Invalid destination URLs, typically missing protocol (www.example.com instead of https://www.example.com)
• Encoded characters, destinations with double-encoded slashes or special characters that Bitly preserves but most browsers re-normalize
• PII in slugs, emails, names, or session-token-shaped strings flagged for review (see the link security guide)

The dashboard lets you resolve each flagged row inline, edit the slug, fix the URL, or skip the row. Once validation passes, the import runs.

Free-tier alternative: API-based import

If you're not on Pro yet, the CSV importer isn't available, but the API is. Write a 30-line script that reads your CSV row by row and calls POST /api/links for each row, respecting the 10-mutation-per-minute rate limit. The API guide covers the patterns. For a one-time migration, upgrading to Pro for one month is faster than scripting.

This is the step everyone wants to skip, and the step that pays the most in saved fire drills. You've imported your links. They now live in Flyn under your branded domain config, but they're not active for users yet, because DNS still points to Bitly. This is your window to validate end-to-end before flipping.

The pre-flip validation checklist

1. Spot-check 10 representative links in the Flyn dashboard. Visit each one. Each should show the right destination, the right tags, the right created_at, and (where applicable) the right title.
2. Test the "preview" redirect on a sampling of high-traffic links. Flyn's preview lets you simulate a redirect without changing DNS, paste the link's test URL (shown in the dashboard) and verify the redirect target.
3. Validate UTM parameters survived intact. If your Bitly links had baked-in UTMs, those should be preserved in the destination URL. Run a sample through the UTM parser to verify all parameters are properly URL-encoded.
4. Run the destination URLs through the redirect checker for high-value links. This catches destinations that have themselves expired or now redirect to login pages.
5. If any of your links were password-protected on Bitly, make sure they're password-protected in Flyn too. Password isn't in the CSV; you have to set it post-import.
6. If you have deep-linked Bitly URLs, decide whether to enable Flyn's deep links toggle on each, the toggle is per-link.

The test-link sanity check

Create one fresh test link in Flyn pointed at any throwaway destination (your own homepage works). Click it from your browser. Click it from a mobile device. Verify analytics show the click in the dashboard. This proves the Flyn redirect engine works for you before you commit production traffic.

When to stop and re-import

If validation reveals more than a handful of issues, fix them in the dashboard (edit individual links) or delete the imported set and re-run the import after correcting the CSV. Don't flip DNS with an unhappy library, every issue you don't fix now becomes a user-facing 404 in 30 minutes.

Migrations break things you didn't expect because team members don't know they're happening. Five minutes of communication prevents an hour of "wait, why is the link from this morning's blog post broken?" panic.

Internal notification template

Send a Slack/email like this:

"Heads up: we're switching our link shortener from Bitly to Flyn this [day] at [time]. Every existing short link will continue to work. The dashboard URL changes from app.bitly.com to flyn.to/dashboard. Your new login is flyn.to/signup, your invite is already in your inbox. If you create new links, do it in Flyn from now on. Anything urgent during the cutover, ping me directly."

Internal docs to update

Anywhere your team has documented "how we make short links", update it:

• Team wiki / Notion / Confluence pages on link conventions
• Marketing playbooks and campaign-launch checklists
• Onboarding docs for new hires
• The link in your team's SSO portal (Okta, JumpCloud, etc.)
• Bookmarks in your marketing manager's browser (smaller but useful)

Things to not tell your audience

End users (your customers, newsletter subscribers, social followers) should not need to know about this migration. The whole point of the slug-preserving CSV import is that links.yourcompany.com/q2-launch keeps working, no one ever sees a "we changed link shorteners" page. Don't announce it publicly; it adds nothing and signals that something might be unstable. Quiet migrations are good migrations.

Internal contact for the cutover window

Pick one person (probably you) to be the on-call for the day of the DNS flip. Make sure they're reachable. Most migrations don't need on-call; the ones that do need it badly.

This is the moment. Everything before this step was preparation; everything after is cleanup. Done right, the DNS change is invisible to users.

Make the CNAME change

In your DNS provider's control panel, find the CNAME record for your branded domain (e.g. links.yourcompany.com). Change the target from Bitly's CNAME value (typically cname.bitlinks.net or similar) to Flyn's value (shown in your Flyn Settings > Domains page, typically routes.flyn.to).

Save. Your DNS provider returns success. From this moment, new DNS lookups around the world will start receiving Flyn's CNAME instead of Bitly's.

Propagation behavior, what actually happens

DNS is cached. Every resolver between your users and your DNS provider has its own cache TTL (Time To Live). When you change the CNAME, here's what propagates and when:

During this propagation window, some users still hit Bitly's servers and some hit Flyn's. Both work, because you imported the links to Flyn but haven't cancelled Bitly yet. This is the engineered overlap, both systems serve traffic correctly during the cutover.

Lower TTL before the migration (optional)

If you have 24-hour TTLs on your CNAME and want the cutover to complete quickly, edit the existing CNAME record 24 hours before migration day and set TTL to 300 (5 minutes). After the cutover stabilizes, raise it back to your normal value. Most teams skip this; the overlap window is harmless.

Verify the new target is being served

Run dig CNAME links.yourcompany.com from your terminal. You should see Flyn's CNAME target. Run it again from a different network (your phone's LTE, a colleague's laptop) to see how propagation is progressing. The redirect checker tests the full chain end-to-end and is the easiest way to verify "is this link redirecting through Flyn now or still through Bitly?"

The successful migration is the one nobody noticed. Your subscribers tap the same link they tapped yesterday; they land on the same destination they expected; the only difference is that the redirect engine in the middle is now yours instead of someone else's. That invisibility is the whole point.

Once DNS has propagated globally (~24 hours after the flip) and you've validated traffic is flowing through Flyn cleanly, it's time to retire Bitly.

Validate propagation is complete

Use a global DNS-checker tool (e.g. redirect checker from multiple regions) to confirm the CNAME resolves to Flyn from every region. If you're in an enterprise environment with corporate DNS, ask a colleague on a different network to verify too. Don't cancel Bitly until you're confident every resolver in the world is serving the new CNAME.

Cancel the Bitly subscription

From Bitly's dashboard, Settings > Billing > Cancel subscription. Confirm. Note the effective cancel date, Bitly typically processes immediately, so check that no further charges are pending.

Important: cancelling the subscription does not delete your Bitly account or the historical data. Free-tier Bitly accounts keep your old data accessible for reference. Don't delete the account, keep it as a read-only archive in case you ever need to look up an old click count.

Update hardcoded URLs in your codebase

If your own product, app, or website has hardcoded Bitly URLs (e.g. bit.ly/help in a static template), those still work through Bitly's own servers, but it's cleaner to migrate them. Grep your codebase for bit.ly and bitly.com:

• Replace each hardcoded short URL with the equivalent Flyn URL on your branded domain
• Update any environment variables or config files
• Update marketing pages, footers, contact pages, "powered by" credits
• Update QR codes (only printed QR codes, digital QR codes generated from short links update automatically)

Set up Flyn integrations to match what Bitly did

If you used Bitly's native integrations (Salesforce, HubSpot, Slack, Zapier), recreate the equivalent in Flyn. Most integrations work via webhooks now, which is cleaner. Step 9 covers the webhook setup.

Archive the Bitly CSV

Store the Bitly CSV export from Step 2 in a permanent, accessible location, your team's shared drive, S3 bucket, or compliance archive. It's the only record of historical click counts. You may need it for retrospective reporting, audit, or "what was the total clicks on that 2024 launch campaign" questions years from now.

The final operational step. You've got working links and analytics, now wire up the automation around them.

Recreating webhook integrations

If you had Bitly webhooks firing into Slack, your CRM, or a custom endpoint, recreate them in Flyn. Settings > Webhooks > Add webhook. Flyn webhooks support:

• link.create, new link created via API or dashboard
• link.update, any field changed
• link.delete, link archived
• link.click, non-bot human clicked a tracked link
• link.expire, link's expires_at passed

The signature-verification pattern is detailed in the webhooks doc and the API guide. Don't skip signature verification, it's the difference between a webhook and a security incident.

Common post-migration webhook integrations

• Slack notifications for high-traffic clicks: subscribe to link.click and post to a channel when the click came from a high-priority tagged link
• CRM updates: when a known-prospect link is clicked (UTM contains a deal ID), update the contact in HubSpot or Salesforce
• Analytics ingestion: pipe link.click into your data warehouse via a custom endpoint or a managed ETL (Fivetran, Airbyte) for blended analysis with your other channels
• Slack DMs to link owners: when a link they created hits 1,000 clicks, send them a "your link is performing" DM

UTM defaults and team conventions

Bitly's UI-level saved UTM defaults don't transfer. Recreate them in Flyn:

• Workspace-level UTM defaults: in Settings > Defaults, set default utm_source and utm_medium values that auto-apply to new links unless overridden
• Use the UTM Builder as the canonical tool for hand-tagged links, bookmark it in your team wiki
• Audit existing UTM hygiene: see UTM parsing & marketing audit guide for the standard sweep

Tag schema cleanup

The CSV import created tags as found in your Bitly export. Many Bitly tag schemas are unkempt, duplicates, inconsistent casing, "test" tags from years ago. Now's the moment to clean up. In Settings > Tags, merge duplicates, delete dead tags, standardize casing. Future tag-based filtering will thank you.

Install the supporting tools

• The Flyn Chrome extension, one-click shortening from your toolbar, custom-domain aware
• API key in your CI/CD pipeline for programmatic shortening (preview deploys, release notes)
• If your team uses Linktree or similar bio-link tools, consider migrating those to Flyn shorteners too, see podcast show notes optimization for a related pattern

Final post-migration checklist

1. All imported links verified working
2. DNS fully propagated globally
3. Bitly subscription cancelled
4. Hardcoded URLs updated
5. Webhooks recreated and tested
6. UTM defaults configured
7. Tags cleaned up
8. Team notified and trained on the new dashboard
9. Chrome extension installed
10. Bitly CSV archived for reference

Three categories of problems account for most migration support tickets. Diagnosing the right category gets you to the fix in minutes.

Category 1: DNS issues (most common)

• "My branded links show an error after I flipped CNAME", likely DNS cache. Wait 30 minutes and try from a different device or network (use mobile LTE to bypass home/corporate DNS). The redirect checker tests from multiple geographic regions to bypass local caching.
• "Some users see the new link, others see an error", propagation in progress. Different resolvers cache for different TTLs; this is expected during the cutover window. Verify Flyn's CNAME target is correct in your DNS settings.
• "My SSL certificate isn't working", Flyn auto-provisions Let's Encrypt certs once DNS resolves. If you flipped CNAME before the cert provisioned, there's a 1-5 minute window where users see a cert warning. The Settings > Domains page shows provisioning status; wait for "Active" before claiming victory.

Category 2: Import data issues

• "Imported links show the wrong destination", check the CSV for special characters in the URL. Bitly sometimes preserves URL encoding that browsers re-normalize. Re-export and re-import.
• "Some links from the CSV didn't import", look at the import-report email Flyn sends after import. It lists every skipped row and the reason. Most commonly: slug conflict with an existing Flyn link, invalid destination URL, or destination longer than the 2048-character limit.
• "Tags imported with weird capitalization", Bitly preserves casing exactly as you entered it. Standardize in Flyn's tag manager after import.

Category 3: Click-tracking issues

• "Click tracking shows zero immediately after migration", confirm the CNAME is pointing at Flyn (not Bitly). If the CNAME is still wrong, redirects are going through Bitly's servers and Flyn's analytics see nothing.
• "Click counts don't match Bitly's historical numbers", they won't. Different platforms have different bot-detection thresholds. Don't compare numerically; compare trends over time.
• "Some clicks aren't being recorded", Flyn's bot detection filters more aggressively than Bitly's by default. If you want to see all clicks including bots, the dashboard has a "show bot clicks" filter. See click fraud prevention for the broader pattern.

Where to go from here

Migration done. The API guide is the next deep dive if you're automating link generation. The link security guide is the deep dive if compliance is a concern. The link management guide covers the ongoing operational patterns. And the Bitly vs Flyn comparison covers the feature-by-feature differences if anyone on your team asks "wait, why did we move again?" And if you are migrating your whole website (not just your shortener), follow our website migration redirect checklist to keep every ranking intact.