How to move a website to a new server

The decision to move has been made and the destination chosen. What follows is the technical part, where the cost of a mistake is measured in hours of downtime and, for a shop, in orders as well.

First, what “without downtime” actually means. For a site with no orders the move genuinely passes unnoticed by visitors. For a shop the answer is different: a few minutes of maintenance mode at the quietest hour, a deliberate trade-off to avoid losing orders. Downtime is measured in minutes, not hours.

Whether a move is needed at all is a separate question, weighed up in our article on your own server versus shared hosting. Here we are concerned with making the transition so that a visitor notices nothing.

What actually moves with the site

Planning starts with a complete list of what lives on the old environment. Whatever is forgotten usually surfaces not on moving day but a fortnight later.

• Site files. Core, theme, modules, uploaded images and documents.
• The database. Page content, products, orders, settings, users.
• Mail on the domain. Staff mailboxes and the addresses the site sends from.
• Domain records. Where the domain points, how mail is configured, which verifications are in place.
• The certificate. Expiry date and how it is renewed in the new location.
• Scheduled jobs. Price imports, mailings, marketplace feeds.
• External connections. Services that call the site on a schedule and know its old address.

The last item is the one most often skipped. An accounting system, a marketplace or a payment provider may call the site by address, and after the move those calls quietly stop working.

Another detail likes to surface later: addresses hard-coded inside the site itself. Links to images, module settings, saved paths to folders. While the address does not change they cause no trouble. As soon as something in the structure shifts, some pages start pointing nowhere.

Once the list exists, the scope becomes visible. A company site moves faster than an online store with integrations and scheduled jobs. We bill the migration at $25/hr and estimate the work in hours for your particular server. After that, you can move on to monthly server administration, so that updates and monitoring follow a schedule. The Basic plan costs $400/mo. What such ongoing support covers is set out in a separate article.

What to do before the switch

A full copy with a restore check

Before anything else, take a full copy of the old environment. It is needed in case the move has to be reversed.

Check the copy immediately. An archive that will not open and a database dump that will not import are discovered in the worst possible way, at the moment they are needed. Fifteen minutes of checking saves a very unpleasant hour.

Along with the copy, record the current configuration. PHP version, database version, enabled PHP extensions, upload size limits and execution time. It does not take long, and on the new server it saves half a day of working out why the same thing behaves differently. What else has to be configured there before the switch is listed in our guide to server setup before launching a website.

Lowering the TTL on domain records

Domain records have a lifetime: how long intermediate servers keep the previous answer. If it is high, some visitors will still be reaching the old server for hours after the switch.

So a day before the move that value is lowered to a few minutes. After a successful switch it is put back. The step costs nothing, but it does not make the change instant. Besides the intermediate servers, the visitors’ own devices hold the previous answer until their own cache expires, so the old server keeps taking part of the traffic for a time. That is why, after the switch, the old server stays in maintenance mode or forwards every request to the new one, so no orders land there.

What to check on the new provider’s side

Before transferring anything it is worth confirming that the new server is actually suitable.

• Versions are compatible with the site. PHP, database and extensions are no older than on the previous host, and newer ones have been tested on a staging copy.
• Key-based access works. And not only for the administrator, but for whoever will run the site afterwards.
• There is somewhere to keep backups. Away from the server itself, not in a neighboring folder.
• The provider responds. A test message to support before the move shows the real response time better than any promise.

Deploying a copy on the new server

The site is brought up on the new server in advance and checked before any traffic reaches it. It is checked not by its public address, which still points to the old environment, but through a local host mapping on the machine of whoever is testing.

What is examined at this stage.

• Every type of page opens. Home, catalog, product page, service page, blog article, utility pages.
• The admin area works. Login, saving changes, uploading an image.
• Checkout goes through. For a shop this is the main test, right down to a payment in test mode.
• Scheduled jobs run. At least one execution of an import or a mailing.
• The error log is clean. Empty after a full pass through the site.

Problems found at this stage are fixed calmly, because the site is not yet serving visitors.

The mail everyone forgets

Mail lives separately from the site, and people remember it after the switch, when messages stop arriving.

Two different things are often confused here. Staff mailboxes are one thing. They can stay where they are, and moving the site does not affect them. Messages sent by the site are another. They now come from a new server, and that is exactly what receiving services see for the first time. So sender verification is checked separately from whether company mail still works.

The quietest problem is not that messages fail to arrive at all, but that they land in junk. The shop keeps taking orders, buyers receive no confirmations, and you only find out from complaints a few days later. In the first hours after the move, place test orders using addresses at several different mail providers and see where the messages land.

Regular checks of small details like this are usually part of a maintenance agreement.

Certificates and redirects

The certificate for the new environment is issued before the switch, if the provider allows it, or immediately after. A gap between the switch and the certificate means visitors see a browser warning, which is noticeably worse than a short outage.

Redirects are checked separately. If the site opened both with and without www, both versions must work in the new location as well. The same goes for the redirect from the insecure version to the secure one.

When page addresses change along with the move, every old one must lead to a new one. Without that, accumulated search rankings are lost, and winning them back takes months.

The moment of the switch and what to do about the database

The most delicate part of a migration is the database. Time passes between taking the copy and making the switch, and in that time new orders or comments may appear on the old site.

The following sequence solves this problem.

• Files are moved first. They are large and change rarely, so they are copied in advance.
• The old site goes into maintenance mode. For a few minutes, at the quietest hour.
• A fresh database dump is taken. Now with no new records, because there is nobody to create them.
• The database is imported on the new server. And the latest orders are checked quickly.
• Domain records are switched. With the lifetime already lowered.
• Maintenance mode is lifted on the new server only. The site is running in its new home.
• The old site takes no orders. It stays in maintenance mode, or forwards every request to the new server.

For a site without orders this dance is unnecessary; it is enough to move everything and switch. For a shop it is essential, otherwise orders placed between the copy and the switch simply disappear.

The window is chosen from analytics, not from a general rule. Look at the hours with the fewest orders over the past month. For most shops the quietest one is a weekday night, but your project may follow its own schedule.

Checks immediately after the move

The first two hours after the switch matter most. The checks follow the same order as the test stage, but now on the live site.

• The site opens from different networks. From mobile data too, not only from the office.
• Forms send mail. And the message does not go to junk.
• Payment goes through. At least one test transaction.
• Analytics is collecting data. Tracking tags in place, events arriving.
• No new errors. The log is checked several times through the day.
• The search engine can see the site. A single page checked through the webmaster tools.

What else is worth tracking in the first weeks is covered in our article on what to do with your website after launch.

What to do if something breaks after the switch

The rollback plan is prepared in advance and is simple. Domain records are pointed back at the old server, and the lowered lifetime speeds that up, though not for everyone at once. The problem is then investigated calmly, without the pressure of downtime.

This only works if the old server remains functional and is not switched off immediately after the move. That is exactly why it is kept running for a while even when everything went smoothly.

If the problem is noticed hours later and orders have meanwhile appeared in the new location, a rollback becomes more complicated: those new records have to be carried back. So for the first two hours after the switch somebody should be watching the site closely rather than doing something else.

How long to keep the old environment running

The old environment is not switched off at once. For a week or two it costs one subscription and gives you somewhere to return to if anything surfaces.

After that, take a final backup, check that it opens, and shut down the old environment. Keep the backup for a few more months, because sometimes someone realizes later that they need a file or a record from it.

It is also worth waiting until the current billing period on the old hosting runs out. The money is spent either way, and a fallback costs nothing.

Typical mistakes that cause downtime

• Moving on a Friday evening. If something goes wrong, you will be sorting it out on the weekend, when provider support is slower.
• The record lifetime was not lowered. Some visitors see the old server for hours, and orders arrive in two places at once.
• Scheduled jobs were forgotten. The price import runs on the old server and shop prices stop updating.
• Versions were not checked. The new server has a different PHP or database version, and some functions fail silently.
• The certificate was issued late. Visitors see a browser warning at the worst possible moment.
• There is no rollback plan. When something breaks, people improvise instead of pointing the records back straight away.

Speed after the move is worth measuring separately: new hardware does not guarantee better numbers if the slowness came from the site itself, and that is covered in our article on why a website loads slowly.

Conclusions

A move without downtime is the result of a set sequence of steps. First a complete list of what is moving, then a copy with a restore check, a lowered record lifetime, deployment and testing in the new location before any traffic, and only then a short window with the switch.

The most expensive mistakes here are organizational: bad timing, no rollback plan and forgotten external connections. All three are dealt with at the preparation stage, and preparation deserves more time than the transfer itself.

If you have a move coming up and would rather not gamble with a working site, send us the address of the project and say where you are planning to move. We will draw up the list of what moves in your particular case, mail, scheduled jobs and external connections included, and name the window with the smallest losses. If some of the problems can be solved by configuration on the current environment, we will show what to change. If the move is needed, we will take the migration on and then look after the server as part of server maintenance.