Last week, I gave some server migration planning tips. This week, I want to continue to flush out what goes into a server migration plan. I hope you find these tips helpful when you move your next server.
Thus far, we’ve touched on server housecleaning, server inventory, DNS migration strategy, and server specifications. You may think that is enough but there are a few more items to consider.
Reducing Downtime
I like to treat downtime as a cost of doing business by asking the simple question, How much downtime can you afford? Reducing downtime during migrations can be challenging, especially if you have a busy web site.
Before moving a server, you need to get a good strategy to keep downtime to a minimum. This is especially true if you are changing DNS. Here are some things I find helpful before starting a migration:
- How quickly I can move the data.
- What happens if data is inconsistent between the servers?
- How will DNS propagation impact your web site?
- Explore my downtime reduction options and costs.
There are dozens of other concerns but these are some key areas that deserve attention. Every application is different. For example, with a static web site DNS propagation will have little impact, but for a discussion forum you would need to keep the data consistent. This may mean closing the forum or using other downtime mitigation strategies.
Picking the right downtime reduction plan will depend on your needs, budget and application.
Data Consistency
Along with reducing downtime, assuring consistent data between systems may be critical. Imagine if blog posts, forum replies or even worse, orders were lost during the migration.
For example, web-based contact forms may email locally. So while you may not worry too much about inconsistent data, a contact form may send the reply to the old server’s email system. You never get this email
Before migrating servers, I like to:
- Identify the data that must be consistent between the servers.
- Identify data that can be out of sync between the two servers.
- Consider the additional downtime required for re-synchronizing any data.
- Identify strategies and tools to help compare data on the two servers.
One too I use heavily is rsync. Rsync allow you to rapidly synchronize data between two locations. Knowing how to use this tool and incorporating it into your migration plan is very useful. I also like to use checksums on critical database files. Having all of your data consistency checks planned in advance assures that when you flip the switch to point DNS to your new server, your data is consistent and ready to go.
Post Migration
Often people spend so much time planning the server move that they forget to consider what happens next. Some things I like to do after the migration:
Have additional staff available to deal with issues.
Watch traffic on the old server to assure DNS propagates correctly.
Look for search engine traffic on the new server
Shutdown services on the old server to check for missed items.
Before canceling the old server, I like to do is shutdown all services on the old server and look for errors. If something did not get ported correctly, this is a good way to find it.
Also don’t underestimate the time required to address new issues. Deepening on your migration strategy, it may take time for traffic to build on the new server. As a result, performance issues may not manifest for 24 hours.
Hopefully these server migration planning tips will help you with your next server migration.
Also, don’t forget to send me your server migration tips.