This article was co-authored by Janet Moss, PMO Lead at William Grant & Sons.
A lot of organisations are discussing and actioning plans to migrate either part or all their workloads from on prem into the Cloud. Regardless of how much you are moving or the size of your organisation everyone must start with the same common start point, a discovery.
Over my time working with customers on migration project everyone’s definition of the discovery phase is different, everyone’s idea of how long the discovery phrase should be and its desired outcomes are different. I want to take you through what I’ve learnt about this phase and share some of my hints and tips.
Sources of Information
Your organisation’s documentation should be the starting point for your discovery. I know documentation isn’t always kept up to date and is often missing some vital information, however it can act as your starting point. You can start to talk to people and ask them questions based on the information you’ve got, rather than starting with a blank piece of paper as that can often be a tough way to start the discovery.
There are several tools that can help you integrate your environment to find out the information that will help you with your migration. The native tooling within Microsoft Azure is Azure Migrate. Azure Migrate can help you assess and migrate on-premises servers, infrastructure, applications, and data to Azure. There are third party tools that can also help you, such as Carbonite, Cloudamize, Corent Technology, Device 42, Turbonomic and UnifyCloud.
People. People within the IT department should be a massive source of information, identify the key ones that you will want to collaborate with you and make sure all aspects of the IT department are included. And it shouldn’t just be the IT department you speak to, speak to the end users and stakeholders in other departments, particularly those that are involved in key business processes, e.g. Finance, customer service, logistics, etc. IT might be the department that keeps that payroll application up and running but your Finance end users who use that application will be able to share information about when the application needs to be available, and potentially information around the lifecycle of the application – maybe they are looking at new solutions and haven’t told you yet. 😉
I mentioned documentation above, and that is a great starting point, but as you go through this phase, start to pull together your own documentation. Think about what the end point will look like for your migration project and build your documents around that. We all know that a picture speaks a thousand words so when talking to people, use system/network diagrams, process maps, rich pictures, flowcharts, swim lane diagrams, etc. These also help to capture and then review what someone has told you to confirm you have correctly identified all the main areas you need to know about as part of your migration work. This is a key part of your discovery phase and will also help to plan out the migration when you get to the planning stage.
This kind of project requires some dedicated time. IT management and their senior leaders need to ensure that proper resource planning is undertaken and that staff are allocated appropriately to deliver this project alongside their business as usual (BAU) activities as well. The people that you pull in to deliver this phase and large project may change as the project evolves so I’m a big advocate of having a Project Manager to help run and organise everything. The Project Manager will be able to be the “anchor” if you are swapping technical resources in and out of the project.
Your discovery phase should deliver you information about your environment and how it is used throughout and as part of the normal daily, weekly, monthly and annual business processes. You should have a complete picture of what is in your environment, you shouldn’t have any gaps or doubts as to what something is. This phase is your opportunity to ensure the delivery phase will run as smoothly as possible therefore every detail should be followed up and documented.
At the end of the discovery phase you should have a lot of information and knowledge of what is there in your environment. This will help you in the next phase of the project, which is figuring out what can move, how it can move and what can’t be moved. Having gathered all the information together you can use it a reference point when you are making the design decisions and catch any of those “gotchas” early. Make sure that you document all your assumptions and exclusions at this point also.
Call to Action
I have written the beginnings of a checklist of the information you should be putting together. I’d love to hear your thoughts and contributions on what information you should be focussing on gathering and sourcing before a datacentre migration.
To understand more about a cloud migration you can leverage the Cloud Adoption Framework and there are some assessments you can work through to understand where your business is and help guide you on the journey.