Ecommerce migrations with minimal downtime

I've led 10+ large ecommerce migrations over the years. A store is a revenue machine, so a migration is not a technical exercise, it's a business operation with a technical part. The goal is always the same: move everything without taking the money offline. ## What actually gets moved An ecommerce platform is not "a website". It's: - the web servers (usually Nginx and PHP-FPM in my world) - the database (MySQL, typically) - the caches (Redis, ElastiCache, or whatever the stack uses) - the DNS, which is the last thing you touch for a reason Each piece moves on its own schedule. The database is the hardest, because it changes every second. The DNS is the riskiest, because it decides where traffic goes. ## The order that works 1. **Build the new environment alongside the old.** Same versions, same config, tested against a copy of the data. 2. **Sync the data, then sync again.** The database gets copied, and then copied again closer to cutover, so the final switch is small. 3. **Point the application at the new stack in stages.** Test the web layer against the new database before anyone's traffic is involved. 4. **Move DNS last.** It's the last dependency and the final lock on the door. DNS propagation means you don't flip it until everything else is proven. ## The part people forget: stakeholders A migration is stressful for the people whose business depends on it. I've learned to keep stakeholders continuously engaged: what's happening, what's next, what could go wrong, and what happens if it does. A migration where everyone knows the plan feels boring. That's a good migration. ## The result Ten plus large migrations, minimal downtime, revenue streams intact. The technique is not magic: it's staging, syncing, testing, and flipping the last switch carefully. Boring, deliberate, and reliable. If you're facing a migration, that's the shape of it. The specifics depend on your stack, but the discipline is the same: move slowly where it matters, and never leave DNS for last.