Experience is a hard teacher because you get the test first, and the lesson afterwards.

I’ve always felt the best lessons are the ones learnt yourself, but to be honest, sometimes I would be more than happy to learn some lessons from others first. I hope the following can help you before you embark on your lift-and-shift migration journey.

Beware the incumbent

“Ok, so he won’t shake my hand or even look me in the eye, oh no this is not a good sign”. These were my initial observations when I first met with the representative of one of our clients Managed Service Provider (MSP). Little did I know how challenging, yet important this relationship was to become.

This is how I saw it. All of sudden after years of this MSP giving your client pretty average service they see you, this threat on their radar. Sometimes the current MSP is also getting mixed messages from the client. What’s wrong? Why the change? What does it mean for them?

I found it best to get the existing MSP on side early. If it’s an exit, then an exit strategy is needed between the client and the MSP. The best results happen when the MSP is engaged and ideally a Project Manager is put in place to assist the client with that exit strategy.

Most importantly, tell your MSP to heed the wise words of Stephen Orban.  “Stop fighting gravity. The cloud is here, the benefits to your clients are transformational, and these companies need your help to take full advantage of what the cloud offers them. Eventually, if you don’t help them, they’ll find someone who will.”

Partner with your client

“Do cloud with your client, not to them”. Your client is going to have a certain way they work, and are comfortable with. Your client will also have a number of Subject Matter Experts (SMEs) and in order to bring these SMEs on the journey also, having someone from your team on-site and full time paired-up next to the SME to learn from them can be invaluable.

There will be things they know that you don’t. A lot actually. I found it best to get your client involved and more importantly their input and buy-in. The outcome will be much better, as will your ability to overcome challenges when they come up.

Lay a good foundation

We spent a significant amount of time working with our client to understand what we were in for. We created an extensive list of every server (and there were 100s) in the Managed Service Providers’ data centre and then set strategies, in place to migrate groups of servers.

We also set up our own version of an AWS Landing Zone as a foundational building block so best practices were set up for account management and security in AWS.

It’s important to lay this foundation and do some good analysis up front. Things will change along the way but a good period of discovery at the start of a project is essential.

But, don’t over analyse!

Do you need a plan? Absolutely. There is a number of good reasons why you need a plan. It sets a guideline and communication within the team and outside it. But I think you can spend too much time planning and not enough time doing.

We started with a high-level plan with groups of servers supporting different services for our client. We estimated some rough timelines and then got into it. And we learnt a lot along the way and then adapted our plan to show value to our client.

Pivot

Mike Tyson once said “Everybody has a plan until they get punched in the mouth”

When things go wrong you need to adapt and change. When we started migrating one particular set of servers out from the incumbent data centre we discovered their network was slow and things ground to a hold during the migration. So, like being punched in mouth, you take the hit and focus on a different approach. We did get back to those servers and got them into the cloud but we didn’t let them derail our plans.

Challenge the status quo

When I started working with a client migration project recently, the team had just finished migrating one of the key databases up into AWS, but the backup process was failing, as the backup window was no longer large enough.

After digging a little deeper, it was found that the backup process itself was very slow and cumbersome, but it had been working (mostly) for years, so ‘why change, right?’! The solution we put in place was to switch to a more lightweight process, which completed in a fraction of the time.

What’s my role, what’s your role?

It’s a really good idea to get an understanding of what everyone’s role is when working with multiple partners. We found taking a useful idea from ITIL and creating a RACI matrix (https://en.it-processmaps.com/products/itil-raci-matrix.html ) a really good way to communicate who was responsible for what during the migration and also with the support of services after the migration.

Not one size fits all.

There are a number of different ways to migrate applications out of data centres and into the cloud. We follow the “6 Rs” for different strategies for moving servers in AWS (https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/).

Although with most servers we used a “Lift and Shift” or “Rehosting” approach in a number of cases we were also “Refactoring”, “Re-architecting” and “Retiring” where this made sense.

Go “Agile”.

In short, “Agile” can mean a lot of different things to different people. It can also depend on the maturity of your client and their previous experiences.

We borrowed ideas from the Kanban methodology such as using sticky notes and tools like Trello to visualise the servers being migrated and to help us limit tasks in progress to make the team more productive.

We found we could take a lot of helpful parts of Agile methodologies like Scrum including stand-ups which allowed daily communication within the team.

And finally but probably most important – Manage Up and Around!

My old boss once told me “perception is reality” and it has always stuck.

It’s critical senior stakeholders are kept well informed of progress in a concise manner and project governance is put in place. This way key stakeholders from around the business can assist when help is needed and are involved in the process.

So, how does this work in an Agile world? Communications are key. You can still run your project using an Agile methodology but it’s still important to provide reporting on risks, timelines and financials to senior stakeholders. This reporting, along with regular updates with governance meetings reinforcing these written reports, will mean your client will be kept in the loop and the project on track.