{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"moving-house","title":"Moving to another provider without losing a URL","url":"https://addaly.com/learn/cloud-and-shipping/moving-house","position":70,"of":74,"minutes":9,"answer":"Migrate in parallel and in order (lower the DNS TTL days ahead, replicate the data continuously, cut over at the quiet hour with the old system still alive.","keyIdea":"Migrate in parallel and in order (lower the DNS TTL days ahead, replicate the data continuously, cut over at the quiet hour with the old system still alive, and serve 301s for every old URL) because the one cost you cannot recover is a link that stops working."},"body":{"format":"markdown","text":"## Everything moves eventually\n\nPrices change, a free tier ends, a provider is acquired, a region closes, or the thing you chose at the start no longer fits. Migration is not a failure; it is a normal event in the life of a system that survives.\n\nIt is also where small projects lose data and break links, because the work is done in the wrong order.\n\n## The order that works\n\n1. **Stand the new thing up in parallel.** Nothing is switched. Deploy the application to the new provider, point it at a copy of the data, and use it yourself on a temporary hostname.\n2. **Copy the data, then keep it in sync.** For a database, a dump and restore establishes the baseline; logical replication or change-data-capture keeps it current so the final cutover moves minutes of data rather than hours.\n3. **Lower the DNS TTL first.** Days in advance. A record with a 24-hour TTL takes up to a day for the last resolver to notice a change; a 60-second TTL makes the cutover reversible in a minute. This step must happen before everything else, and it is the one most often forgotten.\n4. **Run read traffic against the new system** while writes still go to the old one, if your architecture allows it. Any difference in behaviour appears here, without risk.\n5. **Cut over during your quietest hour**, with the old system still running and still receiving data.\n6. **Watch for a day, then a week**, before decommissioning anything.\n7. **Keep the old system's data**, offline, for a month after you turn it off.\n\n## The stateless half is easy; the state is the migration\n\nMoving an application is a deploy to a different place. Moving a database is the actual project, and there are three approaches:\n\n- **Downtime window.** Stop writes, dump, restore, start. Simple, honest, and fine if you can afford ten minutes at 4am and your data is small. Rehearse it and time it first.\n- **Logical replication.** The new database subscribes to the old one's changes and stays current; you cut over when the lag is near zero. Standard in Postgres and MySQL, and the right answer above a few tens of gigabytes.\n- **Dual write.** The application writes to both, reads from one. Powerful, and the most error-prone of the three, because partial failures produce divergence. If you use it, add a comparison job that reads from both and reports differences, or you will find the divergence months later.\n\nFile storage has a fourth trick worth knowing: copy everything in advance, then keep serving reads from the old bucket while new writes go to the new one, and run a background copy for the remainder. S3-compatible tooling (`rclone` is free and excellent) makes this a single long-running command.\n\n> Figure: A migration with an undo at every step. Timeline: Day minus 7, Lower the DNS TTL to 60 seconds; Day minus 5, Stand the new system up in parallel on a temporary hostname; restore a dump, then keep it in sync by replication; Day minus 1, Run read traffic against the new system; compare behaviour; Day 0, quietest hour, Cut over. Old system still running. 301s for any path that changed; Day 1 to 7, Watch. Rollback is one DNS change while the old data is current; Day 30, Decommission, and keep the old data offline for another month. The order is the whole method. Lower the TTL before anything else, cut over with the old system still alive and still receiving data, and decommission nothing for a month, because a same-day decommission is a migration with no undo.\n\n## The costs that appear at the door\n\nEgress is charged on the way out. Moving 5 TB off a provider that charges 9 cents a gigabyte is about $450, payable before you have benefited from the move. Check that number early; occasionally it changes the plan, and occasionally the destination provider will cover it, which is worth asking.\n\nThere are also regulatory rules in some places designed to reduce switching costs for cloud customers, and the picture varies by jurisdiction. Do not rely on it; budget for the bill.\n\n## URLs are the thing you must not break\n\nEvery link somebody saved, every search result, every citation of your content is a URL. Losing them is the one migration cost you never recover, because the traffic stops and nobody tells you.\n\n- Keep the same paths if you possibly can.\n- Where paths must change, serve **301 redirects** from every old URL to its new one, and keep them for years, not months.\n- Check redirects with a crawler before and after: free tools will fetch your sitemap and report every non-200.\n- Do not move the domain and the platform at the same time. One change at a time, a week apart, so you know which one caused the problem.\n\n## Write the rollback down first\n\nBefore the cutover, one page: what \"go back\" means at each step, who decides, and what the deadline is. In practice it is usually \"change the DNS record back and stop writes to the new system\", which only works if the old system is still running and still has current data, which is why steps 5 to 7 above are in that order.\n\nA migration where the old system was decommissioned on the same day is a migration with no undo, and it is the reason most horror stories about this exist."},"check":{"question":"A team plans a provider migration for Saturday. On Friday they are still deciding details, and the DNS record has a 24-hour TTL. What does this imply for Saturday's cutover?","options":[{"text":"Nothing, provided they update the record before starting the migration","correct":false,"tempting":"A change to a record does not shorten the caching of the answers already handed out; the old value can persist for up to the previous TTL."},{"text":"Some resolvers will keep sending users to the old system for up to a day, and reverting is equally slow","correct":true},{"text":"The cutover will fail, since DNS changes cannot take effect while a long TTL is set","correct":false,"tempting":"Overstates it: changes do take effect, gradually, as cached answers expire: the problem is the delay and its asymmetry, not failure."},{"text":"They should switch to a different DNS provider so the change takes effect immediately","correct":false,"tempting":"Caching happens at resolvers everywhere, not at the authoritative provider, so changing provider does not shorten the wait."}]},"prev":{"slug":"the-cost-per-user","title":"What one user costs you","url":"https://addaly.com/learn/cloud-and-shipping/the-cost-per-user"},"next":{"slug":"the-maintenance-calendar","title":"The hour a week that keeps it alive","url":"https://addaly.com/learn/cloud-and-shipping/the-maintenance-calendar"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Moving to another provider without losing a URL', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/moving-house (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Moving to another provider without losing a URL","courseTitle":"Shipping It","module":{"index":8,"slug":"running-it-for-years","title":"Running it for years"},"answer":null,"keyIdea":"Migrate in parallel and in order (lower the DNS TTL days ahead, replicate the data continuously, cut over at the quiet hour with the old system still alive, and serve 301s for every old URL) because the one cost you cannot recover is a link that stops working.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"timeline","title":"A migration with an undo at every step","events":[{"when":"Day minus 7","what":"Lower the DNS TTL to 60 seconds"},{"when":"Day minus 5","what":"Stand the new system up in parallel on a temporary hostname; restore a dump, then keep it in sync by replication"},{"when":"Day minus 1","what":"Run read traffic against the new system; compare behaviour"},{"when":"Day 0, quietest hour","what":"Cut over. Old system still running. 301s for any path that changed"},{"when":"Day 1 to 7","what":"Watch. Rollback is one DNS change while the old data is current"},{"when":"Day 30","what":"Decommission, and keep the old data offline for another month"}],"caption":"The order is the whole method. Lower the TTL before anything else, cut over with the old system still alive and still receiving data, and decommission nothing for a month, because a same-day decommission is a migration with no undo."},"alt":"Figure: A migration with an undo at every step. Timeline: Day minus 7, Lower the DNS TTL to 60 seconds; Day minus 5, Stand the new system up in parallel on a temporary hostname; restore a dump, then keep it in sync by replication; Day minus 1, Run read traffic against the new system; compare behaviour; Day 0, quietest hour, Cut over. Old system still running. 301s for any path that changed; Day 1 to 7, Watch. Rollback is one DNS change while the old data is current; Day 30, Decommission, and keep the old data offline for another month. The order is the whole method. Lower the TTL before anything else, cut over with the old system still alive and still receiving data, and decommission nothing for a month, because a same-day decommission is a migration with no undo."}},"blocks":[{"t":"h2","id":"everything-moves-eventually","runs":[{"text":"Everything moves eventually"}]},{"t":"p","runs":[{"text":"Prices change, a free tier ends, a provider is acquired, a region closes, or the thing you chose at the start no longer fits. Migration is not a failure; it is a normal event in the life of a system that survives."}]},{"t":"p","runs":[{"text":"It is also where small projects lose data and break links, because the work is done in the wrong order."}]},{"t":"h2","id":"the-order-that-works","runs":[{"text":"The order that works"}]},{"t":"ol","start":1,"items":[[{"text":"Stand the new thing up in parallel.","b":true},{"text":" Nothing is switched. Deploy the application to the new provider, point it at a copy of the data, and use it yourself on a temporary hostname."}],[{"text":"Copy the data, then keep it in sync.","b":true},{"text":" For a database, a dump and restore establishes the baseline; logical replication or change-data-capture keeps it current so the final cutover moves minutes of data rather than hours."}],[{"text":"Lower the DNS TTL first.","b":true},{"text":" Days in advance. A record with a 24-hour TTL takes up to a day for the last resolver to notice a change; a 60-second TTL makes the cutover reversible in a minute. This step must happen before everything else, and it is the one most often forgotten."}],[{"text":"Run read traffic against the new system","b":true},{"text":" while writes still go to the old one, if your architecture allows it. Any difference in behaviour appears here, without risk."}],[{"text":"Cut over during your quietest hour","b":true},{"text":", with the old system still running and still receiving data."}],[{"text":"Watch for a day, then a week","b":true},{"text":", before decommissioning anything."}],[{"text":"Keep the old system’s data","b":true},{"text":", offline, for a month after you turn it off."}]]},{"t":"h2","id":"the-stateless-half-is-easy-the-state-is-the-migration","runs":[{"text":"The stateless half is easy; the state is the migration"}]},{"t":"p","runs":[{"text":"Moving an application is a deploy to a different place. Moving a database is the actual project, and there are three approaches:"}]},{"t":"ul","items":[[{"text":"Downtime window.","b":true},{"text":" Stop writes, dump, restore, start. Simple, honest, and fine if you can afford ten minutes at 4am and your data is small. Rehearse it and time it first."}],[{"text":"Logical replication.","b":true},{"text":" The new database subscribes to the old one’s changes and stays current; you cut over when the lag is near zero. Standard in Postgres and MySQL, and the right answer above a few tens of gigabytes."}],[{"text":"Dual write.","b":true},{"text":" The application writes to both, reads from one. Powerful, and the most error-prone of the three, because partial failures produce divergence. If you use it, add a comparison job that reads from both and reports differences, or you will find the divergence months later."}]]},{"t":"p","runs":[{"text":"File storage has a fourth trick worth knowing: copy everything in advance, then keep serving reads from the old bucket while new writes go to the new one, and run a background copy for the remainder. S3-compatible tooling ("},{"text":"rclone","code":true},{"text":" is free and excellent) makes this a single long-running command."}]},{"t":"h2","id":"the-costs-that-appear-at-the-door","runs":[{"text":"The costs that appear at the door"}]},{"t":"p","runs":[{"text":"Egress is charged on the way out. Moving 5 TB off a provider that charges 9 cents a gigabyte is about $450, payable before you have benefited from the move. Check that number early; occasionally it changes the plan, and occasionally the destination provider will cover it, which is worth asking."}]},{"t":"p","runs":[{"text":"There are also regulatory rules in some places designed to reduce switching costs for cloud customers, and the picture varies by jurisdiction. Do not rely on it; budget for the bill."}]},{"t":"h2","id":"urls-are-the-thing-you-must-not-break","runs":[{"text":"URLs are the thing you must not break"}]},{"t":"p","runs":[{"text":"Every link somebody saved, every search result, every citation of your content is a URL. Losing them is the one migration cost you never recover, because the traffic stops and nobody tells you."}]},{"t":"ul","items":[[{"text":"Keep the same paths if you possibly can."}],[{"text":"Where paths must change, serve "},{"text":"301 redirects","b":true},{"text":" from every old URL to its new one, and keep them for years, not months."}],[{"text":"Check redirects with a crawler before and after: free tools will fetch your sitemap and report every non-200."}],[{"text":"Do not move the domain and the platform at the same time. One change at a time, a week apart, so you know which one caused the problem."}]]},{"t":"h2","id":"write-the-rollback-down-first","runs":[{"text":"Write the rollback down first"}]},{"t":"p","runs":[{"text":"Before the cutover, one page: what “go back” means at each step, who decides, and what the deadline is. In practice it is usually “change the DNS record back and stop writes to the new system”, which only works if the old system is still running and still has current data, which is why steps 5 to 7 above are in that order."}]},{"t":"p","runs":[{"text":"A migration where the old system was decommissioned on the same day is a migration with no undo, and it is the reason most horror stories about this exist."}]}],"check":{"question":[{"text":"A team plans a provider migration for Saturday. On Friday they are still deciding details, and the DNS record has a 24-hour TTL. What does this imply for Saturday’s cutover?"}],"options":[{"text":[{"text":"Nothing, provided they update the record before starting the migration"}],"correct":false,"tempting":[{"text":"A change to a record does not shorten the caching of the answers already handed out; the old value can persist for up to the previous TTL."}]},{"text":[{"text":"Some resolvers will keep sending users to the old system for up to a day, and reverting is equally slow"}],"correct":true,"tempting":null},{"text":[{"text":"The cutover will fail, since DNS changes cannot take effect while a long TTL is set"}],"correct":false,"tempting":[{"text":"Overstates it: changes do take effect, gradually, as cached answers expire: the problem is the delay and its asymmetry, not failure."}]},{"text":[{"text":"They should switch to a different DNS provider so the change takes effect immediately"}],"correct":false,"tempting":[{"text":"Caching happens at resolvers everywhere, not at the authoritative provider, so changing provider does not shorten the wait."}]}],"order":[3,2,0,1],"why":null},"prev":{"slug":"the-cost-per-user","title":"What one user costs you","minutes":9},"next":{"slug":"the-maintenance-calendar","title":"The hour a week that keeps it alive","minutes":8}}}