Successful cloud migration is business critical. The right strategic approach can help deliver a smooth transition, minimising headaches and stress, underpinning business continuity and – crucially – ensuring a solution that provides a robust platform to accommodate future tech developments, as well as changing or expanding business needs. In the second of our series on successful cloud migration, Alex Drake, an Azure architect in our Cloud Migration Services Team, explains the importance of a thorough discovery process in developing the right migration process and cloud solution for your organisation
The fundamentals of a cloud migration discovery process
The first step in successful cloud migration is effective planning. Once you’ve nailed this, you’re ready to move onto the discovery process to find out exactly what you’re dealing with.
Discovery provides a thorough assessment of an organisation’s current digital estate. This involves identifying all the applications, systems, and data that need to be migrated and highlights the dependencies between them.
We would normally want to know things such as what hardware does a customer have on premises? What servers does it run and what are their specs: the CPU, the memory, the storage? What applications are in use and what data do they handle? Do the servers talk to one another or are they externally focused?
Creating an inventory of the current digital estate
There are scanning tools available that can automate much of this task. These can help create an inventory that provides a centralised list of all an organisation’s servers, and a profile of their workloads. One commonly used tool is Azure Migrate appliance, which captures workloads and provides a detailed readiness assessment ahead of migrating to Azure. Another is Lansweeper, an IT asset management tool that will, as it says on the tin, sweep your LAN to compile a list of the make and model of every item of hardware, including things like switches and routers, and every piece of software it finds on the network.
Tools like these will provide a readout of the readiness of your servers. Some may be good to migrate as is, while others may have issues flagged; for instance some may be running old and unsupported versions of operating systems that will need an upgrade before they’re ready.
For specific applications, we will map the customer experience from start to finish, to capture information on all assets, such as the client, server, APIs and data and how everything is interacting with everything else.
Understanding the impact of specific workloads on the business
Once we have an exhaustive inventory, we will work with customers to define in greater detail the workloads that will be handled. Here are some of the questions we will typically want to ensure we have answers to:
- What is the primary purpose of the workload?
- Which of the motivations are affected by this workload?
- What is the business impact of this workload?
- Which business unit is responsible for this workload?
- What business processes will be affected by changes to the workload?
- Will there be periods during which, for business reasons, changes cannot be implemented?
- What would be the impact of downtime?
We generally allow time to spend a day or two on site with a customer making sure we have answers to the full range of essential questions. Forewarned, after all, is forearmed; knowing as much as one reasonably can about the nuts and bolts of what one is migrating ahead of the project sharply increases the likelihood of a stress-free and relatively problem-free exercise.
Next, in the third article this series, I’ll look at defining the migration approach
Want to lay the foundations for a successful cloud migration? Get in touch
Read all of our successful cloud migration series articles:
