Migrating From Short.io to yas.sh: Domains, Links, and Automation

Short.io users usually arrive with two assets: a library of links and a custom domain. Both migrate cleanly if the sequence is right. This playbook covers the whole move — data, DNS, and automation — with the failure points called out.

Step 1 — Inventory and export

Export your links from Short.io (their CSV export includes short URL, long URL, title, and creation data). Add the domain inventory: which custom domains are in use, where their DNS lives, and which links depend on each domain.

Step 2 — Prepare DNS for the switch

The domain move is the highest-risk step, so prepare it:

1. Lower the TTL on the domain's DNS records 24 hours before cutover (e.g. 86400 → 300) so the final switch propagates fast.
2. Add the domain in the yas.sh dashboard and note the edge hostname.
3. Pre-flight: point a test subdomain at the new edge and confirm TLS issuance completes (custom domains guide).

Step 3 — Re-create links in bulk

Same discipline as any bulk job — 1/sec pacing, idempotency keys, explicit collision handling (bulk guide):

# one row per link: destination,alias
while IFS=, read -r dest alias; do
  curl -s -X POST https://yas.sh/api/v1/links \
    -H "Authorization: Bearer yas_live_..." -H "Content-Type: application/json" \
    -H "Idempotency-Key: sio-$alias" \
    -d "{\"originalUrl\":\"$dest\",\"customAlias\":\"$alias\"}"
  sleep 1
done < shortio-export.csv

Prefer keeping your Short.io aliases — they're already in print, email, and bookmarks.

Step 4 — Forward old URLs during overlap

During the transition, old Short.io URLs must keep working. Two options:

• Short.io side: keep the account active during the window; its links keep resolving (optionally with its own redirects).
• Own domain: when the domain moves to yas.sh, the same aliases resolve on the new platform — the DNS cutover is the forwarding.

The overlap window is the safety net: any URL still pointing at old infrastructure keeps working until DNS and content settle.

Step 5 — Port the automation

Short.io automation ports cleanly to the OpenAPI-documented API: REST + JSON, Bearer auth, idempotency, and rate limits. The fastest port for typed codebases is regenerating clients from the spec (guide):

// before: short.io client
// after: same shapes, new client generated from https://yas.sh/api/v1/openapi

Walk the automation inventory line by line: link creation jobs, analytics pulls, QR generation, campaign builders. Each maps to a yas.sh endpoint — the webhooks & automation guide has the patterns.

Step 6 — Verify and cut over

• Spot-check 5% of migrated links end-to-end (old URL → new link → destination).
• Confirm the custom domain serves TLS on the new platform (curl -I https://go.yourbrand.com/launch).
• Run a full CSV export and reconcile counts against the source export.
• Announce the platform switch internally; update dashboards and bookmarks.

The failure points, called out

Exporting the data you actually need

The foundation of any migration is a clean export. From Short.io, export every link's full record: the original destination URL, the existing short code or custom slug, the title, any tags, the creation date, and — if you want to preserve analytics — the historical click data. Decide up front which fields you truly need, because carrying over a messy export compounds every later problem. Clean the data in the same pass: normalize URLs, remove duplicates, and fix obvious corruption before it reaches the new system. The quality of the migration is capped by the quality of the source file.

Preserving links and analytics history

A migration has two goals that must both be met: keep every link working and keep the analytics that makes the links valuable. Keep the existing short codes (or map them one-to-one) so anything already published — in emails, on cards, in QR codes — does not break. Set up 301 forwarding from the old domain so old links resolve during and after the transition, protecting both the click path and the SEO value that has accumulated. And carry the historical click counts into the new platform where the destination supports it, so your year-over-year reporting does not start from zero. This is the same preservation discipline as the migrate without history loss guide.

Running the migration as a safe batch

Do not copy links by hand. Use the bulk import pattern — a CSV fed to the API at a paced rate, with an Idempotency-Key per row so retries never duplicate, and collision handling for slugs that already exist in the new namespace. This is exactly the bulk creation CSV workflow applied to a migration. After the import, verify the count matches, spot-check a sample of redirects, and confirm the analytics have transferred before you cut over.

Staging the cutover to avoid downtime

A clean cutover is staged, not abrupt. Run the import and verify it in parallel with the old system. Then switch a low-risk subset of links first, confirm they resolve and track correctly, and finally enable the 301 from the old domain to the new one for everything else. Keep the old domain alive for a period so anything still pointing at it keeps working. A staged cutover converts a risky "big bang" change into a controlled rollout you can pause and correct if anything goes wrong.

Watch for these specific Short.io quirks

Migration-specific issues are worth anticipating: Short.io custom slugs may contain characters that differ from your target namespace, its export may include fields with a different schema, and analytics histories may be stored per-link rather than centrally. Handling these in the cleaning pass — normalizing slugs, mapping fields, deciding how to carry history — prevents the migration from stalling on data you did not anticipate.

Conclusion

Short.io migration is a data job, a DNS job, and an automation job — in that order, with overlap as the safety net. The custom domains guide handles the DNS half, the bulk creation guide the data half, and the OpenAPI guide the automation half. Follow the sequence and nothing breaks.