How to Export Your Links and Data From Bitly

Migrating a link library from Bitly to Flyn is mechanically simple, sign up, import CSV, verify your domain, 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 for a Bitly-to-Flyn migration. Most of the wall-clock time is waiting, for Bitly's export email and for DNS to update, and that waiting runs in the background while you do the rest.

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 importing (the preview is free), 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, open Links and choose Export, then pick the email address the file should go to. Bitly emails a CSV, and a large export can take up to 30 minutes to arrive. Data export is part of Bitly's paid plans (Growth and above on its current pricing page), so a Free or Core account cannot export from the web app. On a plan that includes it, you can also select up to 100 links on the Links page and export just those; that file downloads straight away.

What the Bitly export contains

The CSV has one row per link. Bitly's help lists these columns for the full export (older exports and the select-links export use the names in brackets):

• Link (Bitlink), the original short URL, usually on bit.ly
• Custom Link (Custom Bitlink), filled when the link has a custom back-half, for example on your branded domain
• Destination URL (Long URL), where the link goes
• Title, the display name
• Date created
• Engagements (Clicks), a total for your plan's data window, not per day
• Status, which marks deleted links

Tags are not in Bitly's documented column list, so check your file: if it has a tags column, you can map it during the import.

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 record that points your domain to Flyn: a CNAME to cname.flyn.to for a subdomain, or an A record to 76.76.21.21 for a root domain (your dashboard shows 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: _flyn. followed by your root domain, for example _flyn.yourcompany.com for links.yourcompany.com, with a value that starts with flyn-verify=. Add it through your DNS provider's interface, then click Verify next to the domain in Flyn. With only the TXT record in place, Flyn confirms you own the domain and asks for the CNAME, and the domain stays "Pending" until you flip DNS in Step 7. That is expected, and you can already import links onto a pending domain.

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.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 importer is the workhorse of any migration. Open Links in the dashboard and choose Import links, then drop in the Bitly export. Flyn detects the columns (you can change any mapping), shows a preview of how every link will be created, and creates nothing until you confirm. Links on your branded domain are recreated on it with the same back-half; links on bit.ly get new Flyn links, because that domain stays with Bitly.

The Bitly → Flyn field mapping

The preview runs before the import

Nothing is created until you confirm, and the preview is free on every plan. It counts the links that are ready, the ones that keep working on your own domain, the ones that get a new Flyn link and the rows that need attention, and it checks each back-half against the links already on that domain. What it flags:

• Taken back-halves, the back-half already exists on that Flyn domain. You choose once for the whole import: skip those rows, or give them a random back-half. On your own domain, a random back-half means the old link will not keep working.
• Missing or invalid destinations, an empty cell or a value that is not a web address. These rows are skipped. A destination without a scheme, such as www.example.com, is fine: Flyn adds https://.
• Back-halves Flyn cannot reuse, ones with a slash or characters other than letters, numbers, hyphens and underscores, or words Flyn reserves for its own pages. Those rows import with a random back-half.
• Destinations that are short links themselves, flagged so you can check that the destination column holds the long URLs. A destination that is already a Flyn link is refused.
• Repeated rows with the same destination and short link as an earlier row, which are imported once.

There is no inline editing: fix a flagged row in your spreadsheet and upload the file again, or let the import skip it. When the import finishes, the results screen offers a report CSV with each row's old short link, its new short link and, for rows that were skipped or failed, the reason.

On the free plan: preview first

On the free plan you can do everything up to the import itself: upload the Bitly export, check the column mapping and read the full preview. Running the import needs Pro, Lifetime or Team. The API is not a free workaround, because API keys need a paid plan too, and it creates one link per request under a rate limit. For a one-time migration, upgrading to Pro for one month is the simplest route.

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 and (where applicable) the right title.
2. Check where your high-traffic links go. A link on your branded domain cannot redirect through Flyn until the domain's DNS points to Flyn in Step 7, so there is no redirect to test yet: open each one in the Flyn dashboard and confirm its destination, then test the live redirect with the redirect checker right after the flip.
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 main gap users can hit is a brief one while Flyn issues the SSL certificate.

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 value (usually cname.bitly.com for a subdomain) to Flyn's value, cname.flyn.to (also shown in your Flyn Settings > Domains page).

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. Then click Verify next to the domain in Flyn again: it shows Active once Flyn finds the TXT record and the CNAME pointing to Flyn.

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 redirect the same way, because you imported the links to Flyn but haven't cancelled Bitly yet. The one gap is on Flyn's side: requests that reach it can fail briefly while its SSL certificate is issued.

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 deleted
• link.click, non-bot human clicked a tracked link

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

If your file had a tags column and you mapped it, the import created those tags exactly as written 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. Flyn has no separate tag manager: filter the Links page by tag to find each one, then fix or remove it on the links that carry it. 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 can be a short window where users see a certificate warning. Wait for "Active" in Settings > Domains, then open a few links over https to confirm the certificate is in place.

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", download the report CSV from the results screen at the end of the import (Flyn does not email it). It lists each row with its status and, for rows that were skipped or failed, the reason. Typical reasons: a back-half already taken on that domain, an invalid destination URL, or a destination longer than the 2048-character limit.
• "Tags imported with weird capitalization", if your file had a tags column, the import keeps each tag exactly as written, casing included. Filter the Links page by tag and fix the casing on those links 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.