You can keep a printed short URL when changing providers only if you can keep serving its original hostname and path. Control of a custom domain makes this possible in principle. It does not automatically transfer link mappings, HTTPS certificates, passwords or analytics. A shared provider hostname usually cannot move with your account.
For example, changing go.example.com/guide to a new destination can preserve the printed entrance. Recreating /guide on a different hostname creates a different URL, even if the last part looks identical. These are illustrative addresses, not live migration demos.
First decide who controls the printed hostname
| Existing address | What can move? | Next step |
|---|---|---|
| Provider-owned shared domain | You can export destinations, but cannot take the provider's hostname to another service. | Keep the old service working, obtain a supported arrangement with its owner, or replace the distributed URL and QR. |
| Custom domain you own and administer | The hostname can potentially point to another service; each existing path must be supported there. | Inventory mappings, check compatibility and arrange the domain transfer before changing DNS. |
| Agency, employer or former supplier's domain | Only what that owner authorizes and can keep available. | Resolve ownership and operating access before planning a move. |
Editing the old link to point to a new short link can be a temporary bridge, if the old provider allows it. That bridge still depends on the old provider, account and hostname. It is not an independent migration.
Domain ownership is useful control, with responsibilities: renewal, DNS access, account recovery and the cost of running the replacement service. Keep those with the organization that needs the printed links. See why working QR codes can stop opening.
Build an exact mapping before choosing a replacement
Download the blank migration worksheet (CSV). It is a planning record, not a file to upload directly to 302.sh. Do not put passwords or private access tokens in a shared worksheet.
| Record | Why it matters |
|---|---|
| Hostname and exact path | Preserve case, trailing slashes, encoding and nested paths where present. Do not silently normalize old printed URLs. |
| Destination and query behavior | Record the full target and whether incoming query parameters replace, append to or are dropped from it. |
| Protection and routing | Inventory passwords, expiry, visit caps, device/country rules and split destinations separately from the default target. |
| Verified on the new service | Record the actual tested address, response, final destination, time and any failures. Leave it blank until checked. |
| Rollback | Keep the previous provider configuration, DNS values and a person responsible for restoring service. |
Obtain every export page and reconcile the count with your inventory. Pause link edits during the final export or maintain a change log so updates made after the export are not lost. A download labelled “complete” still needs a check against the links you actually distribute.
Keep the original QR artwork and decode representative printed addresses. An exported slug alone does not identify which domain was printed. Historical reports are a separate archive; do not expect a new provider's visit totals to include traffic recorded by the old one.
What a move to 302.sh currently supports
Check these conditions before purchasing a plan or moving a hostname. They describe the current implementation; this article does not report a completed cross-provider migration.
- Custom subdomains: setup supports a subdomain such as
go.example.com, not an apex such asexample.com. A paid plan and completed domain activation are required to serve links on it. Use the records shown in Domains; the custom-domain guide explains setup. - Exact path compatibility: custom slugs use letters, digits, underscores and hyphens, with a structural length of 3–32 characters. Nested paths, dots and shorter slugs do not fit this format. Availability checks apply on the selected hostname. Reserved page names are blocked on shared hosts; that reserved-name restriction does not apply on your custom hostname. A new alias is not a fix for an incompatible printed address.
- CSV import is a separate feature: it starts at Pro. The current importer creates links on
3go.to; it does not accept a custom hostname. Buying custom-domain access does not turn CSV import into a migration that preserves your domain. - Import fields: the supported columns are
target,slug,expiresAt,commentandpassword. Supply a bare slug, not a full short URL. Header aliases do not extract a path from a URL. Conflicting slugs are skipped; inspect each row's result. - Custom-domain mappings: create eligible links explicitly on the activated domain through the regular dashboard link workflow, selecting that domain. Confirm domain onboarding and exact path creation with a small controlled trial before any production cutover.
- Settings and history: the CSV fields do not transfer smart-routing rules, split tests, visit caps or historical analytics. Exported password markers are not reusable passwords; re-establish the intended protection and test it.
For query parameters, when query forwarding is enabled, 302.sh forwards visitor parameters and lets them replace destination parameters with the same key. With forwarding disabled, the stored target is used without those visitor parameters. If the stored target contains utm_source=email and the incoming link has ?utm_source=poster, the resulting target uses poster. Check this against your old provider's behavior, including repeated parameters and protected-link flows. This URL example describes a rule, not a traffic measurement.
If the original host or paths are incompatible, keep the old serving arrangement or choose a replacement that supports them. Creating new 302.sh addresses is useful for new distribution, but it does not preserve existing printed addresses.
Rehearse on a domain you are authorized to change
- Agree the onboarding order. Ask both services how the same hostname moves, when ownership must be released, and whether HTTPS can be prepared before routing changes. A hostname already attached elsewhere may need provider coordination.
- Use an isolated test subdomain. Recreate representative valid paths and destinations there. Include a mixed-case path and query conflict. Keep production DNS untouched during this rehearsal.
- Test the complete path. Verify domain activation, a valid HTTPS certificate, the expected redirect status and Location, and the final page. A dashboard's “active” label alone is insufficient.
- Test failure cases. Check unknown paths, expired/protected links and any device or country rules you use. Confirm that unsupported settings are visible in the migration record.
- Rehearse rollback. Restore the prior serving arrangement and verify it. Keep the configuration and file backups needed for that recovery.
Use a fresh visitor session as well as technical HTTP checks. A preview on a different hostname checks content and mappings, but cannot prove the certificate or routing works for the actual printed hostname. This runbook has been checked against product source and automated behavior tests; no live DNS cutover, provider-to-provider transfer or physical QR test was performed for it.
Cut over with a recovery window
- Confirm all required mappings and settings have a passing result. Save a final export and record changes made since the rehearsal.
- Record the existing DNS records and TTLs. If your DNS provider supports lowering TTL in advance, allow the previous TTL to elapse before relying on the shorter value.
- Change only the agreed records for the short-link hostname. Keep the old account and configuration available where the providers permit it.
- Check the actual printed URLs over HTTPS, including query parameters and representative QR images. Observe both old and new serving paths while caches change.
- If critical links fail, use the rehearsed recovery procedure. DNS rollback can also take time; restoring a record is not proof that all visitors have recovered.
There is no universal “wait five minutes, then cancel the old provider” rule. DNS caches, TLS provisioning, provider release requirements and previously cached redirects vary. Retire the old arrangement only after the new one has been verified over an appropriate observation window and rollback dependencies are understood.
If all you need is a new destination within the same service, a provider migration may be unnecessary. Our destination-edit test shows the narrower operation: keeping one short address and saved QR image while changing the target, including an observed delay before the new target appeared.
What is included in 302.sh?
Free allows 5 new links per UTC month and up to 50 owned links, with 5 custom slugs per month of at least 6 characters. Deleting a link does not refund its monthly creation allowance.
Free includes 2,000 analytics events per month and 90-day retention. Reaching that analytics allowance stops additional tracking, not redirects. Link deletion, owner-set limits and safety enforcement can still stop redirects. Branded domains require a paid plan and completed domain setup. See current plans and limits.
Try the workflow
Explore the dashboard demo, or create a short link using a destination you own or are authorized to share. Verify the destination before distributing it.