Planning a server migration is a complex task. But it’s also an opportunity to build a scalable hosting architecture for the future. The success of a migration to your new setup is all in the planning. So read this article, and get your thoughts in order before you begin.
This article will be useful if you’re planning to move hosting platform or provider, upgrade to a more powerful dedicated server, or migrate to a more scalable cluster architecture. We’ll address the broad planning areas, and what to consider at the outset of your migration project. We won’t provide specific scripts and step-by-step instructions here, but you will find some links to other resources.
Part One: Preparing to Migrate
The most simple migration we’re talking about is a migration from one dedicated server to another. This may be to upgrade, outsource or change hosting provider. At the other end of the spectrum, you may be migrating to a clustered architecture, perhaps even in stages that let you test the new servers, keep your databases up to date and avoid (or minimize) downtime.
New Server Architecture
Let’s get this out of the way early – migrating is complex. But it’s also a great opportunity to get things right so that you don’t need to migrate again any time soon. iWeb’s system architects can help you with both your migration to our data centers and with identifying the best, most scalable, most redundant and most cost effective new solution. If you have any questions or doubts, get in touch.
If you’re still at the stage of considering what architecture to use, consider deploying a server cluster to improve performance and make managing/scaling your architecture simpler. A cluster is a logical step up from a single server, and can save you downtime and further migrations in future. You can find out more about some typical types of advanced or clustered solutions here:
Whatever you decide, there are certain hygiene factors to consider before you begin the process of migrating. You should ensure that you have sufficient disk space and processing power on your new servers, plus a 30-40% overhead, or a more detailed projection and scaling plan. Also make sure you have enough IP addresses, and a fast network port of 100Mbps or more.
Any changes to your server architecture, OS, software versions or control panels will necessitate some changes to the configuration of your servers. In fact, even if you are upgrading to a more powerful server, it is likely that you can you can configure your services to take advantage of additional RAM, CPU power, drives or RAID.
Thoroughly planning and documenting the deployment process and configuration requirements will help this process run more smoothly, and help you when looking for outside help, as will having a DevOps team who are already familiar with your application and your deployment process.
The simplest way to migrate is to recreate your entire server on your new server hardware, then configure and thoroughly test it, then make the switch from the old to the new servers by changing the necessary DNS or IP settings. Although even this simple strategy takes system administrators to set up your new servers, it is relatively simple in terms of planning.
The downside of this process is that it involves freezing all code changes and locking the database on your old server while the new server is set up, and/or synchronizing the data between your old and new database before changing the DNS or IP settings. Otherwise you will lose any code/data changes made during the migration process.
The problem with freezing changes to your servers and locking your database during migration is that in many real-life scenarios you need to provide normal services to users of the server throughout the process of migration. While moving a bunch of files may be easy enough, moving a business critical service or a constantly updating live database presents the problem of avoiding downtime, maintaining user access and permissions, and ensuring data continuity. That means you may not be able to lock your database, freeze development or let your service go down at any time during the (potentially quite long) migration process.
A popular way to address this is to perform a hybrid migration strategy. This involves preparing the new servers, synchronizing the old and new servers, and staggering the switch over. For example:
- For a database server: Begin with the old database as the master, and the new (tested and configured) database as the slave. This will synchronize the databases. Once the servers are synchronized, and the new database is up-to-date, reverse the master-slave roles so the new database becomes the master. The desired result is no downtime, no locking the database and the chance to switch back to the old database if anything should go wrong. You can find information about database replication for MySQL here.
- For web and application servers: Use a load balancer to share traffic between the new and old servers, providing a live test. Once the new servers are proven to work as planned, direct all the traffic to the new servers. Once again, there is no downtime, and you can point all traffic to the old server should there be any unforeseen problems.
These two processes can themselves be staggered so as to concentrate efforts and limit risk to on one aspect at a time.
Preparing your current server
Before migrating, clean up your current server by removing old sites, backups and email accounts that you are no longer using. This makes your server as lean as possible during the migration, and helps provide an accurate idea of the storage and computing requirements of your new server.
If you settle on a migration strategy that needs you to freeze development during the migration process, consider the timing and impact of a development freeze (during this time modifications to scripts, files and configurations cannot be made). Plan the timing around your business requirements and add this to your migration strategy.
Consider the impact of locking your databases, which can be considerable if they are updated by many different users (e.g. a website CMS, customer account information). If it’s not possible to lock your databases, you will need to plan a final update as part of your migration strategy, so that when you switch server, your database is replicated and up to date.
Most migration strategies involve backing up your server in order to transport it to its new location. Whether or not this is your chosen method of transporting the data, be sure to take a full backup of your server before you migrate.
And don’t close down your old server, or close your old hosting account, before your new server or website is live and functioning correctly. You may need to switch back, or your live date may be delayed.
Part Two: Tools and Services
For relatively simple migrations between similar servers (perhaps between two shared web hosting providers), certain tools can help you migrate a website without detailed understanding of how to configure a website.
For relatively complex migration services, you can use bespoke services that provide specialist expertise and support. These services can cost several hundreds of dollars, but this will be a wise investment if you are not sure you have the resources to handle a migration, or you want to make sure that you are migrating to the most scalable long term solution. If you are migrating to iWeb, we can help with all of this.
If you are moving between shared web hosting providers, with no change to the operating system or software, control panels like cPanel and Plesk can be useful for backing up your files and restoring on the new server, with little reconfiguration required. You can see this in action in this useful guide for switching shared web hosting providers.
Migrating Wordpress themes and CSS is very easy, and simply requires the transfer of files between the old and new servers using FTP or a backup program. Migrating the database is a little more tricky, but there are several plugins designed to automate the process and make it a bit easier. Here is a review of some of those plugins.
SSH / root access
The most likely scenario for more advanced hosting setups, the command line, usually accessed via SSH, can be used to transfer an entire database from one server to another, followed by all permissions and user data. For MySQL (the most common open source database), this is done using MySQLdump – here’s an example case study. If you use Windows, SQL Server can be migrated between servers using built in tools, as described here in the Microsoft Knowledge Base.
IaaS / hosting providers
Using a professional IaaS / hosting provider like iWeb to migrate your services has the advantage that we have the expertise needed to help you first decide the best new server architecture, then migrate and configure your new servers. You may want your developer, system administrator or database administrator to configure the different services on your new server, although a good IaaS provider like iWeb can also do this for you.
If you’re calling on a hosting provider to help with migration, it’s probably because you have a more advanced set up (at least dedicated hosting, perhaps a server cluster). Migration between these types of servers can mean several hours work, which could carry a price tag of $100-$1000, depending entirely on the complexity of your servers.
Some other services specialize in website migration, including switching hosting provider or migrating to clustered architectures. Offering a similar service to IaaS providers for migrating websites, at broadly similar prices, these services can take migration completely out of your hands and guarantee that your application is functioning as before. The global leader in website and application server migration services is iWeb partner WSM.
Part Three: Migration Checklist
Hopefully that’s just enough information to get you started with your migration strategy, or set your mind at rest in the knowledge that you have covered all the bases. Here’s everything we have covered, summarized as a list of questions to ask yourself before you begin planning your migration.
- Should you change the architecture, computing power, OS/software versions or file structure of your servers?
- Do you have the necessary human resources to identify the new architecture’s requirements and opportunities, and configure your new servers correctly?
- Having identified your new solution, does your hosting provider give you the storage, bandwidth, computing power and reliability you need for now and the near future?
- How scalable is your new hosting architecture – can you easily improve it, upgrade it or migrate it if you need to?
- Should you freeze changes to files on your existing server, and when should you do this in order to allow enough time for the migration (plus testing).
- How much downtime is acceptable, and how can your migration strategy reduce downtime? Is avoiding downtime worth adding complexity and resources to the process?
- How will you update/manage your databases in order to ensure data continuity and not lose data that is changed during migration? Do you need to lock your database in order to achieve this?
- Do you have a plan in place to ensure that users have the correct privileges on the new server.
- How will you thoroughly test the new servers using realistic loads?
- What will be the impact of the changes on server users and how will you manage this? Who is affected, and what steps do they need to take.
Good luck planning your migration. For help identifying and deploying a new hosting solution, and for expert support migrating your servers, get in touch with iWeb. It’s what we’ve been doing since 1996.
No comments yet.