OK folks, Twitter may be a fad, but it is also a wealth of information into real people’s problems, and I don’t think it is going away anytime soon.
In fact Google and Yahoo announced recently that they are going to begin crawling tweets, and they will appear in search queries. So yes, I am a fellow “twit,” and proudly so, because I know how to use it to find the information that I am looking for and can then chat with fellow twitterers about issues.
Here are the top five server migration mistakes that I’ve seen tweeted:
1. Server Downtime
Server downtime is probably the most-heard concern when performing a migration. This is because most migration processes require the source server be offline, either during the conversion process or during the recovery. If the solution doesn’t require the server to be offline, then they won’t tell you they require the application to be offline and not accessible to the users, which is no different then having the server down.
High availability solutions have now addressed this issue through real-time replication that can transfer the data to the new platform while the server and application remain online and available to users and then failover with minimal interruption. This process has been used for over 15 years now to minimize downtime for business-critical systems for disaster recovery, so why not use it for a server and hardware migrations?
2. Late Night and Weekends
Get your weekends back. One of the greatest myths about server migrations is that they need to be performed during off-hours when no one is using the servers or server data that is being migrated. This is usually because the server migration can’t capture changes to the data after the migration starts.
This is typical of most physical-to-virtual conversion processes; once the virtual migration starts, none of the data can be accessed, and if the servers is online and available, a differential restoration is required to capture the changes that did occur.
This isn’t the case with asynchronous replication migration products, where data can change on the older server and replicate to the migration target server in real time. Because of real-time replication, migrations can be performed during normal business hours and then failed over to the target server once all the data changes have been captured and transferred to the new system.
3. P2V Conversion Process Failed
There is a reason why it was free. Actually there are two: first, either it is beta and doesn’t work and the company is looking for feedback; or second, it works great and they want to capture market share.
I have seen too many tweets from people complaining about the pain of the P2V (physical to virtual) process or virtual server migration they are going through, but they can’t be bothered to spend a couple hundred dollars for a product that works and can make the nightmare go away.
I can’t say I have much sympathy for those who try to perform critical functions with free tools that promise the world, but I have to admire the ambition — not intelligent, but you have to respect the tenacity.
4. Hardware Not Compatible
I hate when that happens.
There is nothing worse than getting within spitting distance of the finish line and breaking your leg. Some of the most common mistakes that I have seen tweets about occur because of hardware compatibility lists not being checked. Here is a hint: Check the HCL (hardware compatibility list) before you start the migration, and while you are at it, check to see if the applications being run are also compatible with the virtual platform to be migrated.
If you are using an OEM-activated license of Windows and changing hardware platforms, then that code will be invalid with the new hardware. Check with the migration product vendor that there is an opportunity to change the Windows Product Key before you complete the migration.
Many companies will say they have this capability, but I know of only one that provides the ability to insert a volume license key as the final step to the migration process., A little planning can go along way, but having a tested P2V conversion process that can perform consistently and also minimize downtime will keep you from pulling out your hair like my fellow “twits.”
5. Migration Succeeded but Drivers Don’t Load
So, the migration’s been completed, only none of the drivers are compatible, and there begins a whole new nightmare.
There are many reasons why this happens, and it could be any combination of the factors mentioned above. Is it the free tool that was downloaded to perform the migration, the hardware being migrated, or the virtual platform? Who knows, but there are solutions on the market that allow you to “set and forget” and avoid this monster of a driver conflict issue.
Here is a hint: Don’t migrate the drivers. Use a shared iSCSI boot image to load up the OS of choice, and then migrate the rest of the system workload. If you don’t have a virtual server provisioning software, then you could load a boot image or re-install, but at least this way you can guarantee that all the services will start with the compatible drivers.
In summary, have a tweet before you perform your server migration and ask the fellow twits what works best for them and what to avoid. Tweet me to learn more about server provisioning or performing successful physical and virtual server migrations to independent hardware platforms at http://twitter.com/brennels.
Brace Rennels is CBCP (certified business continuity professional) at Double-Take Software.
Loading ...
