Cloud migration: what “good” looks like
Cloud migration is a complicated process, but it's no dark art, and overcoming some of the most common pain points is often just a case of sufficient preparation. And yet there's often a reticence in the mid-market to regard migration as the critical process it is.
For larger organisations, processes must be bulletproof, with clear, accountable owners assigned to every aspect. Migration at this level is necessarily laborious, and the organisations carrying them out simply can't afford the catastrophic disruption that failure would cause.
But it's rare for smaller companies to even anticipate migration projects, let alone have a firm grasp of best practice. Obviously smaller companies don't merit the hundreds of man hours of planning that large organisations do – but efforts must be scaled down in a relative fashion rather than starting from scratch and meeting needs as they arise.
Hasty migrations tend to end in one of two ways: 1) the migration process is ill-planned and therefore likely to encounter difficulties, or 2) the destination environment fails to live up to the unreasonable expectations placed on it. Establishing standardised processes relevant to the size and complexity of your organisation not only saves money on initial discovery and scoping exercises with migration consultants, but aligns the outcome of the migration itself to more long-term business need.
From A to B in five easy steps
Planning – Planning for a migration is much the same as planning for any other IT project, but given the intensive nature of migrations, your migration partner will require a level of transparency that is perhaps not needed in other projects.
Certain conditions, such as a lack of disk space must be factored in to the migration strategy. These types of issues can be overcome, but failing to highlight them at an early stage could unexpectedly impact the chance of a successful migration.
Proof of Concept – Always recommended. It's essentially a dry-run using non-critical data, allowing you to pilot the system with minimal risk. You'll either be reassured that your actual migration will go ahead without a glitch, or you'll be made aware of potential issues that can be addressed. Win-win.
Migration – You've got two main options when it comes to migrating a large amount of data. In short, we can summarise these options as either moving all the data at once in as short a time as possible (which will include some scheduled downtime to cope with the increased load), or moving discrete elements of the environment in the background (which takes considerably longer, but has less chance of something going wrong).
Testing – Testing is the point at which you give your migration the chance to fail. Don't be too cautious at this stage; your tests should be rigorous enough to identify any potential points of failure (better now than weeks after completion). How long you take to test depends – we've known the testing stage to take anywhere from half a day to 3 months, depending on the size of the organisation.
Go Live – This is the only point in the process where scheduled downtime is necessary (apart from imaging). Many organisations are tempted to go live very late at night on a weekend because of a presumed sense of security. But it's generally best practice to go live at around 7am on a Monday morning. That way, if anything went wrong, you know you'll be able to get hold of the relevant people that can help get you back online in as little time as possible.