Meet Scott Slater, Senior Solutions Architect at VirtaMove. Scott is offering 5 key tips for a successful WS2K3 migration. Scott has been one busy guy since joining VirtaMove in 2013. With Windows Server 2003 end of extended support looming on July 14, 2015, he’s been rolling up his sleeves and guiding organizations faced with moving applications from legacy Windows servers, often under less-than-ideal conditions.
Scott favors plaid shirts, and it suits him well. He’s kind of like the proverbial Canadian lumberjack, hewing his way deftly through forests of application migration proofs of concept, felling potential problems as he goes.
Scott estimates he’s assessed and guided over a dozen application migration projects in the past six months, most of them highly complex in nature. Beneath Scott’s soft spoken exterior is specialized expertise derived from direct experience with real-world challenges. Scott understands the potential pitfalls that may lurk in the application migration landscape so he builds relationships with key people who will be performing the migrations so they can nimbly side step these difficulties. Scott’s job is to ensure migration success, and modest as he is, he’ll eventually admit to a very high success rate in the field. This success rate is thanks to a rigorous Migration Methodology that guides migration players end to end, from evaluation to findings through a pilot cycle that typically last two to three weeks.
In short, Scott’s a good guy to have on your side. His time as migration lumberjack can save you loads of time and effort, and he comes with tried-and-true tips for success – five of them, in fact.
#1 – Get App Owner Buy In
Scott doesn’t have to think too hard or long about his number one tip: Who is your application owner? For instance, who’s the go-to person when the application you want to migrate fails or must be upgraded? Getting the app owner on board enables the migration team to delve into the application and all its complexities. This deep dive provides all parties with an understanding of the application’s components and pieces and how they work together. Not understanding is likely to mean that a migration will fail very quickly in the pilot exercise.
Scott remembers a pilot project where the application owner was not exactly forthcoming in discussions about the application; as a result, those involved in the project didn’t quite understand how the application worked. Forty five minutes into an eight-hour migration window, the migration fell on its face. Next time – same application, same organization, but better conversation with the application owner – the migration was successful with two hours to spare in the migration window. So, Scott says, “You’ve got to get that total buy in and involvement from the app owner, from the get go.”
#2 – Map That App
Now that you’ve got the app owner on board, “Get to know your application in all its complexity,” counsels Scott. Is it multi-tiered, does it have no passwords or 15 passwords, does it feature a database backend that requires re-hosting, does it have components on separate servers, is it a web app? The more you know about the app you want to migrate, the better.
Holes in application knowledge can cause missteps. Scott can think of a case where the app had an encryption key associated with it, but no one knew about it. It was discovered, unfortunately, during the migration process itself. Looking up error messages, trying to come up with a workaround or a solution significantly delayed the migration.
#3 – Ready Your Resources
The migration methodology spans a pretty condensed time frame. You don’t have an endless window to get that app moved – think two or three weeks max. That’s not a lot of time to mobilize required people and technical resources. You’ve got to get that destination server provisioned and meeting technical pre-requisites; key human resources have to be available and not booked on vacation. If not, things get delayed, and the more delay the less likely that migration will be successful for non-application reasons.
Scott remembers a proof of concept exercise with a large vendor, where the prevailing attitude was one of “Oh, I’ll get to it. The server will eventually be provisioned, at some point.” Thanks to the absence of urgency, the change window passed, and a new change window was required. This entailed change management requests. Not surprisingly, the exercise was significantly delayed. What should have taken a couple of weeks took several months. “Sometimes,” Scott says, “you don’t have the luxury of months and months to move your applications.”
#4 – Know Your Environment
Great: you now have buy in from the app owner and the server admin, the application you’re moving is all figured out, and your resources are aligned and mobilized. What’s next? Figure out the infrastructure gotchas. The more you know about your environment, the better prepared you will be.
You’ll need to make sure that, among other things:
- the destination server has the capacity to run the application you are migrating;
- you have credentials for the accounts that will be used during the migration and by the application;
- required ports are open;
- all antivirus software (which can interfere with VirtaMove software) is disabled;
- end to end connectivity is available for all components;
- required applications are installed on the destination server.
Scott points out a case where antivirus had indeed been disabled prior to a migration; however, IT Security noted that antivirus had been turned off, and duly enabled it on the server overnight. As a result, failures cropped up during the migration the next day. Once antivirus software was disabled again, everything went well, though not without extra work and some delay. In retrospect, knowing about IT Security policies and forwarding a change request to IT Security would have prevented the problem.
#5 – Test. Test Again. And Test Some More
Thanks to all your preparations, the migration rubber hits the road. You’re going zero to sixty in no time, and you feel the wind in your hair. Following VirtaMove’s rigorous migration methodology, with Scott riding shotgun beside you, means success at this stage.
Now’s the time to thoroughly test the application while it’s still tethered in its container. Use all of the components and features of the application to make sure that everything is working as expected and the application is viable on the destination server. There’s no such thing as too much testing. For example, right-click operations in SQL Management Studio will not work untethered if they were not exercised while tethered.
Once user acceptance testing (UAT) of the application is complete, the application can be removed from its container and installed onto the destination operating system, removing any dependency on VirtaMove software. Now the application has been fully migrated onto the new destination server and the legacy Windows 2003 server can be decommissioned.
“Success,” Scott says, “is not dependent on any one component but all components and players contributing to a clear migration vision, goals, expectations, rollout, and success criteria.” In application migration, research and planning go a long way toward ensuring success.