[{"data":1,"prerenderedAt":408},["ShallowReactive",2],{"switcher-blog-pareja":3,"art-migrate-vps-zero-downtime-en":6},{"en":4,"es":5},"\u002Fen\u002Fblog\u002Fmigrate-vps-zero-downtime\u002F","\u002Fes\u002Fblog\u002Fmigrar-vps-sin-downtime\u002F",{"id":7,"title":8,"author":9,"body":10,"date":393,"description":394,"extension":395,"image":396,"meta":397,"navigation":398,"pareja":399,"path":400,"seo":401,"stem":402,"tags":403,"__hash__":407},"blogEn\u002Fen\u002Fblog\u002Fmigrate-vps-zero-downtime.md","How to migrate a VPS with zero downtime: the method we have been applying for years","Paco Cubel",{"type":11,"value":12,"toc":375},"minimark",[13,18,22,25,29,34,37,56,59,63,71,84,91,95,98,116,119,135,142,146,149,153,179,183,186,190,255,259,331,335,341,347,353,359,363,366],[14,15,17],"h2",{"id":16},"why-this-matters","Why this matters",[19,20,21],"p",{},"Any business that lives online has a recurring nightmare: that the website goes down right when a campaign starts, on a long weekend or the day the big customer decides to come in. And migrating the server is one of the moments where that risk concentrates the most.",[19,23,24],{},"The good news is that most migrations can be done without anyone noticing. The bad news is that they require method, not improvisation.",[14,26,28],{"id":27},"the-four-phase-method","The four-phase method",[30,31,33],"h3",{"id":32},"_1-audit-of-the-current-environment","1. Audit of the current environment",[19,35,36],{},"Before touching anything, we list:",[38,39,40,44,47,50,53],"ul",{},[41,42,43],"li",{},"Exact versions of every piece of software (PHP, MySQL, Nginx\u002FApache, Node.js, etc.).",[41,45,46],{},"System dependencies (PHP extensions, native libraries, APT packages).",[41,48,49],{},"External services calling the server (third-party cron jobs, webhooks, integrations).",[41,51,52],{},"Volume of data on disk and in the database.",[41,54,55],{},"Firewall rules, SSL certificates and current DNS.",[19,57,58],{},"Without this map, any migration is a lottery.",[30,60,62],{"id":61},"_2-parallel-replication","2. Parallel replication",[19,64,65,66,70],{},"We build the new server in parallel, ",[67,68,69],"strong",{},"without touching production",". We replicate the data:",[38,72,73,81],{},[41,74,75,76,80],{},"Files via ",[77,78,79],"code",{},"rsync -avz --delete",", scheduling several passes until the delta is minimal.",[41,82,83],{},"Database with a full dump and, on large databases, binlog replication so the destination is almost up to date.",[19,85,86,87,90],{},"We test the new website on an internal domain or a tweaked ",[77,88,89],{},"\u002Fetc\u002Fhosts",". We validate every flow: user signup, forms, payments where applicable, external integrations.",[30,92,94],{"id":93},"_3-cutover-plan-with-rollback","3. Cutover plan (with rollback)",[19,96,97],{},"This is the secret. Before the cutover:",[38,99,100,106,113],{},[41,101,102,105],{},[67,103,104],{},"We drop the DNS TTL to 5 minutes"," 24 hours in advance so propagation is almost immediate.",[41,107,108,109,112],{},"We write a ",[67,110,111],{},"documented rollback plan",": what changes, in what order, and how to undo it if anything goes wrong.",[41,114,115],{},"We notify the customer of the exact moment and the low-risk window.",[19,117,118],{},"On cutover day, we run:",[120,121,122,129,132],"ol",{},[41,123,124,125,128],{},"A final ",[77,126,127],{},"rsync"," pass with the site in read-only mode (just a few minutes).",[41,130,131],{},"DNS switch to the new server.",[41,133,134],{},"Immediate verification: the site responds, the form works, the SSL certificate is valid.",[19,136,137,138,141],{},"If everything is fine, we move on. If anything fails, ",[67,139,140],{},"we revert the DNS"," and the website continues working as before on the old server, without anyone noticing.",[30,143,145],{"id":144},"_4-post-cutover-validation","4. Post-cutover validation",[19,147,148],{},"24 hours watching logs, uptime monitoring and metrics. Any odd behaviour is diagnosed live. When we have several green days, we shut down the old server (not before).",[14,150,152],{"id":151},"common-mistakes-to-avoid","Common mistakes to avoid",[38,154,155,161,167,173],{},[41,156,157,160],{},[67,158,159],{},"Migrating without prior replication",": moving live is a coin flip. Always clone first, test, then cut over.",[41,162,163,166],{},[67,164,165],{},"Forgetting cron jobs",": cron jobs on the old server keep firing if you don’t disable them, and can produce duplicates or repeat charges.",[41,168,169,172],{},[67,170,171],{},"Not testing real forms",": sending a test email from the new server isn’t the same as receiving it on the customer’s account.",[41,174,175,178],{},[67,176,177],{},"Not lowering TTL early enough",": if DNS takes 24 hours to propagate, half of the traffic goes to the old site for that long.",[14,180,182],{"id":181},"how-long-it-usually-takes","How long it usually takes",[19,184,185],{},"A standard small-VPS migration is done in 2–3 weeks: one for audit and replication, one for testing, one for cutover and support. Don’t aim to do it over a weekend, except for trivial cases.",[14,187,189],{"id":188},"the-method-at-a-glance","The method at a glance",[191,192,193,209],"table",{},[194,195,196],"thead",{},[197,198,199,203,206],"tr",{},[200,201,202],"th",{},"Phase",[200,204,205],{},"Typical duration",[200,207,208],{},"Risk if skipped",[210,211,212,223,234,245],"tbody",{},[197,213,214,217,220],{},[215,216,33],"td",{},[215,218,219],{},"2–3 days",[215,221,222],{},"Hidden dependencies break things on cutover",[197,224,225,228,231],{},[215,226,227],{},"2. Parallel replication + testing",[215,229,230],{},"1–2 weeks",[215,232,233],{},"You arrive at cutover day not knowing what works",[197,235,236,239,242],{},[215,237,238],{},"3. Cutover plan with rollback",[215,240,241],{},"1 day (in writing)",[215,243,244],{},"If something fails, you waste hours improvising under pressure",[197,246,247,249,252],{},[215,248,145],{},[215,250,251],{},"1–3 days",[215,253,254],{},"Issues that surface 24 h later with no one watching",[14,256,258],{"id":257},"planned-migration-vs-ad-hoc-migration","Planned migration vs ad-hoc migration",[191,260,261,274],{},[194,262,263],{},[197,264,265,268,271],{},[200,266,267],{},"Aspect",[200,269,270],{},"Planned migration",[200,272,273],{},"Ad-hoc migration",[210,275,276,287,298,309,320],{},[197,277,278,281,284],{},[215,279,280],{},"Total project time",[215,282,283],{},"2–3 weeks",[215,285,286],{},"One weekend",[197,288,289,292,295],{},[215,290,291],{},"Real perceived downtime",[215,293,294],{},"\u003C 5 min, optional",[215,296,297],{},"1–8 hours (or more)",[197,299,300,303,306],{},[215,301,302],{},"Probability of needing rollback",[215,304,305],{},"\u003C 5 %",[215,307,308],{},"30–50 %",[197,310,311,314,317],{},[215,312,313],{},"Surprises in production after cutover",[215,315,316],{},"Few",[215,318,319],{},"Almost guaranteed",[197,321,322,325,328],{},[215,323,324],{},"Real cost (firefighting included)",[215,326,327],{},"Predictable",[215,329,330],{},"2–3× more",[14,332,334],{"id":333},"frequently-asked-questions","Frequently asked questions",[19,336,337,340],{},[67,338,339],{},"Will there be downtime?","\nWe aim for zero. Most of the time we get it. If by the nature of the change it’s unavoidable, we plan it for low-traffic windows and communicate it to the client well in advance.",[19,342,343,346],{},[67,344,345],{},"What if something goes wrong?","\nWe have a written rollback plan before the cutover. If something doesn’t fit, the service keeps running on the old server while we fix it.",[19,348,349,352],{},[67,350,351],{},"Do you migrate large databases?","\nYes. We’ve migrated databases of several gigabytes using continuous replication to keep cutover downtime to a minimum.",[19,354,355,358],{},[67,356,357],{},"Do I need to switch hosting provider?","\nNot necessarily. The migration can be between different providers, between machines of the same provider, or even to on-premise infrastructure. The method adapts.",[14,360,362],{"id":361},"wrap-up","Wrap-up",[19,364,365],{},"Migrating a VPS without downtime isn’t magic: it’s discipline. The hardest part isn’t technical, it’s the upfront planning. On cutover day you only execute what has already been validated.",[19,367,368,369,374],{},"If you have a pending migration and would rather have a team with real scars handle it, ",[370,371,373],"a",{"href":372},"\u002Fen\u002Fcontact\u002F","drop us a line"," and we’ll tell you how we’d approach yours.",{"title":376,"searchDepth":377,"depth":377,"links":378},"",2,[379,380,387,388,389,390,391,392],{"id":16,"depth":377,"text":17},{"id":27,"depth":377,"text":28,"children":381},[382,384,385,386],{"id":32,"depth":383,"text":33},3,{"id":61,"depth":383,"text":62},{"id":93,"depth":383,"text":94},{"id":144,"depth":383,"text":145},{"id":151,"depth":377,"text":152},{"id":181,"depth":377,"text":182},{"id":188,"depth":377,"text":189},{"id":257,"depth":377,"text":258},{"id":333,"depth":377,"text":334},{"id":361,"depth":377,"text":362},"2026-04-22","A poorly planned server migration costs money. Here is the step-by-step method we use at Atenea Systems to move websites and services without the end customer noticing a thing.","md","\u002Fog\u002Fog-default.png",{},true,"migrar-vps-sin-downtime","\u002Fen\u002Fblog\u002Fmigrate-vps-zero-downtime",{"title":8,"description":394},"en\u002Fblog\u002Fmigrate-vps-zero-downtime",[404,405,406],"Migrations","Linux","Servers","bY35MSTpB4V2VV2lp07UYKZQf5gBJ9e7zQandxbt29c",1781154908004]