Cutover Do’s and Don’ts

You’ve migrated your workload and synchronized your data, your application owner has smoke tested their application within the new cloud environment and the cutover date is quickly approaching – how do you ensure this goes off without a hitch and avoid that dreaded call from your customer at 2am?

If you’ve spent time in the trenches of Managed Hosting, you know how painful migrating some workloads are and you know that those same machines can be some of the most critical!  So how do you plan appropriately for this?  This can be a large topic depending on your experience, but Racemi has many years of expertise in this realm. We know that no matter how good your tools are or how good your team is, cutover can make or break a mass migration.

Here are some basic tenants you want to include in your plan and if you stick around to the end, we’ll share some traps (IT’S A TRAP!) you’ll want to avoid:

Cutover Do’s

  • Identify Stakeholders – Identify your Application Owners, Solutions Architects, Migration Engineers and anyone directly related to the workloads you are moving. This could include the Admin team for both the source and destination environments, as well as any Network Engineers responsible for the pipes you intend to traverse.  These people need to be listed in your Runbooks with contact info.  If possible, they should be included in prep calls and at a minimum, should be on call for the cutover in case things get messy!
  • Create an Update Channel – Slack, Email, checkpoint meetings… pick your poison, but make sure to include everyone and provide regular updates, even if the update is merely to report that everything is going as planned.
  • Schedule Early – Schedule cutovers well in advance, allowing your customers to get the message and Application Owners to plan accordingly. Communicate this to everyone impacted by the operation.
  • Synchronize Late – After the maintenance window is open, you want to be sure to quiesce services and apps on your workloads and do a final synchronization only after you can be completely sure that the workload is not being utilized. This will allow you to ensure data consistency with both your source and target environments.
  • Validate UAT Results and Signoff – Your Application Owners should’ve blessed the target workload long before the cutover window opens. Remember that only they know how their application should behave and fully understand the SLAs around those applications.  As Project Manager or Migration Engineer, it is your responsibility to validate that this testing was completed.  DO NOT attempt to cutover a workload to a new production environment without explicit sign off from your application owners.

Cutover Don’ts

  • Don’t Thread the Needle – Everyone involved is going to put pressure on this event. Everyone is going to want it done yesterday. It’s your job to ensure that adequate time is available to facilitate a smooth migration.  Don’t try to be a hero with your commitment here – you need ample time to move these machines without the pressure of short window.  Depending on the number of machines you are migrating, this might include smaller windows spread out over the course of a weekend.  Fighting for the appropriate number of hours is your job and you should arm yourself with Runbook Data and your Migration Plan to back you up.  If you’re the acting Project Manager, work with your folks and listen to their estimates – this is not the time to pressure them into a window that they are not comfortable with.
  • Don’t Go it Alone – DynaCenter does a fantastic job of automating many of the tasks associated with the cutover operation, but we’re all humans and we make mistakes. It’s never a bad idea to bring one or more friends along for the ride.  Cutover operations should always include checks and balances of peer review co-pilots to ensure everyone is making good decisions, especially when these occur in the middle of the night!
  • Don’t Jump off the Ledge – You need a rollback strategy incase something doesn’t go right. Luckily, Racemi has you covered here!   When you use DynaCenter to migrate your applications, we NEVER compromise your source workloads.  If something goes wrong with the cutover, you always retain the ability to rollback to the source environment.
  • Don’t Forget To Communicate Success – After a long weekend of cutovers, it’s tempting to close the laptop and hit the couch, but remember that many people are awaiting your final updates so, take time to announce your success and ensure that everyone involved acknowledges it before you crash! Nothing worse than waking up to an inbox full of mad customers because you forgot that final DNS change.

We hope you found this helpful!  We love cloud migrations and want to work with you.  Give us a shout and we’ll show you why Racemi is the best choice for migration services and technology.

 


Pin It on Pinterest