How to Migrate Your Web App to New Hosting Without Downtime

You can migrate web app hosting without downtime if the new environment is fully built and tested before you touch DNS, and if you've decided in advance how the database moves and how you'd roll back. Done that way, the switch is a short, planned moment instead of a Saturday night of hoping for the best. The hard part is rarely the code. It's the data that keeps changing while you move: orders, sign-ups and uploaded files.

I'm a freelance developer based in Denmark and handle hosting migrations as part of my maintenance work, so weigh my section on when you don't need a developer with that in mind. Moving to an EU-based provider for GDPR reasons? The plan is the same, with one extra item near the end.

The short answer: a migration timeline

A zero-downtime migration is mostly about sequence. Everything that can break should break on the new server before a single customer is sent there.

Here's the decision rule. For visitors who only read, downtime can almost always be avoided entirely. For data that gets written, you're choosing between a few minutes of planned write freeze and a more involved replication setup. Most small and mid-sized web apps are better off with the first.

A hosting move is part of ongoing web application maintenance, and it gets much easier when the rest of that work is already in good shape.

Steps 1-3: preparation is where migrations are won

Most of the work happens before the switch. Good preparation makes cutover day boring, which is exactly the point.

1. Map every dependency. The code is the easy part. What gets forgotten is everything around it: cron jobs (scheduled tasks), queue workers, uploaded files, environment variables and API keys, SSL certificates, the PHP version and backup jobs. Check whether an integration only accepts requests from your old server's IP address (an IP allowlist), and whether other systems send webhooks to a fixed address. If your email is hosted with the provider you're leaving, the MX and SPF records have to come with you, or email stops working.

2. Build the new environment and test it with real data. Set up the server, deploy the app and import a copy of the production database. Point your own machine at the new server using your hosts file (a local file that overrides DNS for your computer only), and you can log in and complete a purchase on the real domain while everyone else stays on the old server. Match the PHP and database versions of the old server. Updating your framework and dependencies is its own project, so do it before or after the move, never on the same night.

3. Lower the TTL well in advance. TTL (time to live) controls how long networks cache which server your domain points to. If it's set to a day, some visitors can land on the old server for up to a day after the switch. In its guide to moving a site without URL changes, Google recommends lowering the TTL at least a week before the move. My rule of thumb is 5 minutes (300 seconds) around cutover. Local DNS caches can still take longer to update, as Cloudflare notes in its TTL documentation.

The database decides how much downtime you get

Files and code can be copied at your leisure. The database is different because it changes constantly. Copy it on Monday, switch on Tuesday, and every order and sign-up in between is missing. There are two sound ways to handle this.

A brief write freeze: the simple, safe option

You pause all changes, take a final database export, import it on the new server and switch. In Laravel that's php artisan down, which serves a maintenance page with a 503 status code, and with the --secret option you can still get in through a bypass URL to test, as described in Laravel's maintenance mode documentation. The freeze lasts as long as the export, transfer and import take. For a small or mid-sized database that's typically minutes, but measure it during the dry run instead of guessing.

Strictly speaking, that's a short outage. It's also planned, announced and scheduled for your quietest hour, and for most web apps it beats a complex setup that can fail in new and creative ways.

Continuous replication: when even minutes are too much

If your app has users around the clock, say a SaaS with customers from Lisbon to Singapore, or the database is too large to move in a few minutes, the new database can follow the old one in real time. In MySQL this is called replication: the old server is the source, and the new one is a replica that receives every change as it happens, as covered in the MySQL replication documentation. PostgreSQL and most managed database services offer the equivalent. At cutover, you wait until the replica has caught up, promote it to primary and move writes over.

The cost is more setup and more to test. It's the right answer for apps that genuinely need it, and overkill for an internal tool with 50 users who work nine to five.

What gets missed at cutover

• Uploaded files. Sync them several times in the run-up and once more during the write freeze, or move them to object storage before the migration.
• The old server must stop writing. While DNS propagates, some visitors still reach the old server. If it saves data to the old database, you end up with two versions of the truth. Have it show the maintenance page or forward traffic to the new one.
• Sessions and queues. If login sessions are stored as files on the server, users get logged out at cutover. Rarely a disaster, but you should know in advance. Drain pending jobs before you stop the old workers.

Steps 4-7: cutover day

With the preparation done, cutover day is a checklist to follow. It's not the day for clever ideas.

4. Do a dry run. Run the whole procedure against a staging environment with a fresh copy of the data, and time it. Write the sequence down as a timed runbook so nobody improvises. This is where you find out the import takes 40 minutes, not 4.

5. Pick the time and tell people. Find your lowest-traffic window and warn users well ahead if there will be a write freeze. Confirm that whoever runs the cutover has access to the domain, DNS and both servers before you start.

6. Run the cutover. Put the app into maintenance mode, or wait until replication has caught up. Take a final backup, sync data and files, move the cron jobs and switch DNS. Finally, make sure the old server no longer writes to any database.

7. Test like a customer, straight away. Log in, create something, complete a payment, reset a password and check that emails arrive. Confirm that cron jobs, queues, uploads and webhooks work, and watch the error log for the first few hours. If you don't have monitoring yet, now is a good moment to add it, and I compare the options in my roundup of uptime monitoring tools for web apps.

Your rollback plan

A rollback plan isn't pessimism. It's what gives you the confidence to go ahead. It has three parts:

• A stop rule. Decide beforehand what sends you back, for example login or payments failing with no fix within 30 minutes. Without a rule, teams end up debugging in production all night.
• An owner. One person makes the call, and it's rarely the developer alone. How long a fault may affect customers is a business decision.
• A technical way back. With a low TTL, DNS can point at the old server again quickly. The tricky part is data written on the new server after cutover. The sooner you spot a problem, the less has to travel back, which makes the testing in step 7 the most important fifteen minutes of the migration.

Back up right before and right after cutover, and make sure the backup actually restores. My guide to a web app backup strategy that holds up covers what that looks like in practice.

After the move: keep the old server alive a little longer

Google's guidance is to keep the old hosting running until the server logs show no more traffic and both users and Googlebot get content from the new infrastructure. That can take days. Meanwhile, there's some cleanup:

• Raise the TTL back to normal once you're sure you're staying.
• Confirm that backups run on the new server. The backup job died with the old host, and people tend to notice only when they need a restore.
• Point monitoring and error tracking at the new server.
• Update your documentation and password manager, and revoke the old credentials.
• If the app processes personal data, sign a data processing agreement with the new host, as Article 28 of the GDPR requires, and check where data and backups physically live.
• Keep a final snapshot of the old server before you cancel the contract.

Expect to pay for two hosting plans for a few weeks. It's cheap insurance.

When you don't need a developer for this

Not every migration needs a plan like this one. In these cases you can often handle it yourself or with your host's help:

• A standard WordPress site or simple website with no logins or orders. Plenty of hosts offer to migrate it for you.
• A static site or a frontend on Vercel or Netlify, where the move is mostly a DNS change.
• Shopify, Wix and similar, where the platform owns the servers. There's only a domain to repoint.

You do want a developer when the app has a database that changes all day, payments, integrations behind an IP allowlist, queues and cron jobs, or when nobody quite knows how the old server was set up. That last one is the real risk, because the server then has to be reverse-engineered before it can be rebuilt. If the codebase is showing its age, the move can be a good prompt to look at modernizing a legacy PHP application, but run that as a separate project.

Next steps: write the migration plan before you cancel anything

Start with the dependency list. You can draft it without being technical, and it quickly shows whether the move is an afternoon or a small project.

If you need someone to write the plan and run the cutover, here's how I handle maintenance and ongoing development for existing web apps. A migration is often a good moment to sort out the rest of your operations too.

Frequently asked questions

How long does a web app hosting migration take?+

Plan for roughly one to four weeks of calendar time from decision to decommissioned old server, even though the cutover itself often takes under an hour. Some of that waiting is deliberate: the TTL needs lowering a week ahead, and the old server should keep running afterwards. The actual workload depends mostly on how well the old setup is documented.

Will changing hosting providers hurt my SEO?+

Not if your URLs stay the same and the site responds normally from the new server. Google says crawl rate often dips right after the move and recovers over the following days. Make sure your Search Console verification still works after the migration and keep any downtime short. Changing domain or URL structure at the same time is a bigger job that needs redirects.

Does moving to an EU hosting provider make my app GDPR compliant?+

No, not on its own. EU hosting can simplify questions about international data transfers, but the GDPR covers how you process personal data wherever it sits. You still need a data processing agreement, a lawful basis, sensible security and a view of your provider's sub-processors. Treat the move as one part of compliance, and ask a privacy lawyer if your situation is unclear. This isn't legal advice.

Do I need to move my email when I change hosting?+

Only if your email is hosted with the provider you're leaving. If it runs on Microsoft 365 or Google Workspace, just make sure the MX, SPF and DKIM records carry over unchanged if you also move DNS. If the app sends email directly from its server, the new server has to be authorized in SPF, or messages land in spam. A transactional email service removes that dependency.