Cloud Migration Strategy: A High-Level Four (4) Step Approach

What's consulting in the Cloud Migration and Process Automation space like? Well... sometimes cloud migrations can feel like the picture below - but really nothing is changing except where the data is stored or where the programs are executed.

How much time do you have? Ideally, 80% of any migration strategy can be planned out in advance with the expectation of 25-30% re-work will be needed to get the last 20% completed. The reason I stated, “Ideally,” is because that is assuming the implementation timetable allows for proper planning is just that - it is an assumption… a major project profile attribute is Time and each program’s schedule is different and as time gets truncated that 25-30% quickly grows to >50% of re-work required in order to ensure a successful migration.

#1 - Gain an intimate understanding of the Business Processes:

For any cloud migration effort – significant attention and time should be taken to understand the business processes that are supported by the various IT systems; learn their criticality, learn their availability needs, their capacity requirements, do they need to scale for burst traffic or are their fairly stable, seasonality...etc. It is also important to get a clear understanding of their business triggers, inputs, outputs & interfaces with any other processes as these points will explain how a specific process fits into the overall service portfolio. Another point of concern here is the technical currency of the current tool-set's underlying infrastructure and if there are any transitional risks due to a generational gap in technology.

#2 - Define detailed Procedures to operationalize the Business Processes: Once the processes are understood (get the high-level-strategy right and business use cases understood first) then we need to construct procedures that explain how to perform the process in operational terms. These procedures should explain all specific nuances of any given process and should also detail any inter-process hand-offs or interactions. Get a clear understanding of all interfacing processes (touch-points defined in terms of when, how, what is being handed off etc) and ensure all interfacing parties have consistent expectations. Any templates or forms/formats should be identified or developed and ultimately these procedures will be provided to the tools development team(s) as the basis of tool requirements.

#3 - Pick COTS tools or develop the tools needed to support the Processes: Once the Processes and Procedures have been conceptually mapped and initial tool requirements have been developed – look to identify if there are any Commercial-Off-The-Shelf (COTS) products that could be licensed or if the Organization is lucky enough to have its own in-house development crew – develop a tool that enables business users to provide equal or hopefully better service standards than they are currently providing all at a lower overall cost.

#4 - Perform thorough User Acceptance Testing (UAT) and/or Service Pilot: Find folks that really want to see what this thing can do and get them to try and break it and no matter how frustrating it gets have them report back any issues they find. Use Agile tools like JIRA, Version One, or the Agile module found within ServiceNow etc to track and prioritize Stories into Sprints. These Sprints can be used to plan / schedule going forward and help Program Management visualize the migration's progress. Pilot programs can limit exposure by identifying any critical flaws, providing an opportunity to learn from typical user profiles / patterns of business activity as well as providing a critical feedback cycle prior to mainstream consumption. The ultimate goal of the UAT/Pilot should not only be to find bugs but also to confirm that the new service satisfies the business process' needs by delivering the expected outcomes in a timely manner.

Throughout a Migration - General Point about Client Relations when in a Consulting environment: Client-facing meetings should be guarded extremely carefully – any interacting personnel's emotional intelligence should be evaluated (program success or well-being should always be primary focus). Additionally, presentation rehearsals should be mandatory prior to any Client engagement and there should be an internal review of all performed content. Said review should be owned by a panel of fierce devil’s advocates looking to poke holes anywhere possible as well as hopefully identifying any points of potential confusion or places where it would be good to have additional support data if needed. If something doesn’t make sense to the group than it is definitely not going to make sense to the Client. Better to sweat in private than bleed in public!