If you’re preparing for a major migration project, you’re at a crucial juncture.

Whether you know it or not, you’re currently standing on a precipice; the choices you make today will determine how things play out in the future.

With the right preparation, you can ensure the project is a success. With an inadequate or ill-conceived approach… well, there may be some uncomfortable home truths to face in the wake of your re-homing.

Regardless of your sector—whether financial, government, retail, communications, or anything else—here are four steps to help you prepare for a major application re-homing project.

1. Determine whether you will re-home the applications to an existing Digital Platform, or something that is built for purpose.

A Digital Platform is a bespoke Platform as a Service (PAAS) product, made up of people, processes and tools. It enables teams to rapidly develop, iterate, and operate Digital Services at scale.

If you intend to migrate legacy applications away from physical infrastructure, you need to consider where they’re heading.

Your organisation might have a relatively new platform. In many cases, it seems self-evident that the newly migrated applications should be housed on the newly built platform. People tend to think: ‘We’ve built this new platform, so we should house the migrated applications there; that’s exactly why we built it, right?’

In reality, it’s not that simple.

In some cases, there may be issues in moving the legacy applications onto the new platform. This can create new work—or unwanted project interruptions—for both the development team managing the new platform, and the team overseeing the migration project.

Ask yourself: Are we migrating these applications to the best possible—and most appropriate—location? Or are we being impacted by a form of recency bias?

Could we purpose-build a platform that is more suited to the specific objectives we need to achieve as part of this migration?

Learn more with the Equal Experts Digital Platform Playbook.

2. Think about how you can map development teams to better support and reflect your organisational structure.

If you’re migrating legacy applications from physical infrastructure to the cloud, there’s a good chance you’ll go through a concurrent process to change the way development teams support those applications in the future.

One approach to consider is ‘you build it, you run it’. This approach to development and support is significantly more efficient than a traditional waterfall or handoff-based team structure.

For example, when we migrated 55 legacy applications to the cloud with Her Majesty’s Revenue and Customs—a non-ministerial UK Government Department involved in the collection of taxes and other regulatory regimes—we rearranged team structure to focus on services, business units and applications, rather than development practices.

Originally, the teams were structured like this:

• Development Teams
• Regression Testing Teams
• Deployment Teams
• Post-production Support Teams

After re-arrangement, teams consisted of:

• One team focusing on all self-assessment tax applications
•  One team responsible for VAT and business tax applications
•  One team managing all applications supporting personal tax, aside from those required in self-assessment
• One team overseeing all other applications, including international tax, health applications, and other comparatively lower usage applications

This approach is beneficial for scaling the migration once the project is in full-effect, and—with the right processes in place—ultimately puts your teams in a better position to monitor, update and maintain the applications moving forward.

3. Consider the effort of the migration project when calculating ‘cost vs. benefit’.

Always remember to factor for the resource associated with the migration project itself. There is a cost associated with re-homing the applications—regardless of whether you choose to re-architect or engage in a simple lift and shift—and you should factor in that cost in any benefits case you develop.

It can be costly to assume that migrating applications away from physical infrastructure automatically creates a reduction in infrastructure cost. And if you don’t factor in the effort involved in the migration process itself, or strategically prioritise your effort throughout the project, it could be even more costly.

4. Bring all major stakeholders along for the journey, from day one.

Of course, whether you re-home to an existing environment or a bespoke Digital Platform and regardless of the approach you take to the migration, you need buy-in and support from Operations, Development and Senior Executive teams throughout the organisation.
A successful major migration project typically impacts multiple teams within an organisation. The more people who have context of the project, knowledge of its objectives, and an understanding of the challenges or constraints you’re navigating, the better.

Contact us!

Of course, there’s much more involved in a successful migration project. For more information, take a look at our HMRC case study. If you’d like us to share our experience with you, please get in touch in the form below.

Picture the scenario. You’re a large organisation ready to migrate ~40 business-critical customer service applications to a new platform and hosting environment.

You’re prepared for the migration. You’ve asked the key questions to consider beforehand. You know which applications will benefit from moving, and which can feasibly stay put.

Now, all you need to do is roll up your sleeves and start re-homing. Well, not exactly.

First, you should always pause to establish cost of delay; it’s a relatively simple exercise that creates significant benefits throughout delivery.

By calculating cost of delay, you can strategically prioritise your efforts in the project lifecycle.

In turn, you’ll be in a much stronger position to:

• Immediately migrate the applications which create the most cost benefit
• Reduce your infrastructure costs incrementally throughout the course of the migration, rather than delaying savings until the end of the project
• Realise intangible benefits sooner, like increased speed-to-market for feature updates or new revenue streams associated with the deployment of completely new services.

So, what are you waiting for? Let’s look into cost of delay.

What is cost of delay?

Cost of delay is an indicative calculation used to measure and understand the benefits you stand to lose by delaying a decision. It can relate to the delay of a migration, a feature update, or a production deployment.

In the context of a migration, think about it this way: if you move a specific application in four or five months as opposed to today, what prospective value do you stand to lose? In calculating cost of delay, you should factor for:

• Loss of potential revenue streams
• Loss of prospective or existing customers due to slow release cycles
• Unnecessary outlay on outdated infrastructure, particularly if you’re re-homing from physical infrastructure to the cloud.

Cost of delay is not:

• The total cost of the project itself
• The potential monetary value you stand to gain as a result of successfully migrating the applications.

It is purely the potential benefit you lose—or the clear cost—of a process being delayed.

How do you calculate cost of delay?

Cost of delay is calculated using a formula.

However, remember that cost of delay is an indicative representation. It’s a tool you should use to establish context around priority relative to other efforts; not necessarily a gilt-edged dollar and cent value. This is because it’s impossible to predict cost of delay to any level of exacting specificity, and it’s a largely wasted effort trying to do so.

The formula is:

Cost of delay = user–business value + time criticality + risk reduction and/or opportunity enablement.

Understanding the terms in this equation:

User-business value:

What value do you create by making this decision sooner for the user or the business? This could involve eliminating existing costs for the business, delivering new features to market for users, creating new revenue streams for the business, or improving the experience of a certain application that might help you to acquire or retain more customers.

Time criticality:

Is there a fixed and compelling deadline for this work? Or for this specific application? Will the value that we’re able to secure obviously decrease the longer we leave it?

Risk reduction/opportunity enablement:

How does this effort facilitate future beneficial work and projects, and will this effort reduce the likelihood of negative impacts on the performance of the application/service in future? For example, in the context of a migration, moving to the cloud might decrease the possibility of server outages, but it also creates the ability for teams to release in faster deployment cycles.

With cost of delay established, you can meaningfully prioritise your migration effort.

Once you have a cost of delay for the overall project and each application, you can strategically prioritise the order in which you migrate those applications.

There are no hard and fast rules as to what, or how, you prioritise. It depends on your organisation, your circumstances, and your objectives for the project.

You might prioritise based on cost reduction: moving applications that allow you to reduce expensive third-party hosting contracts. You might prioritise for value realisation: moving applications to establish a faster release cycle, so you can get new services to your customers sooner.

Regardless of how you choose to prioritise, the point is this: With cost of delay established, you can prioritise. You’re empowered to create the most value possible for your organisation.

Let’s look at a tangible example from our work in re-homing 55 legacy tax applications with Her Majesty’s Revenue and Customs.

The project involved migrating 55 complex tax applications from physical servers to the cloud. If the team decided to move applications randomly—rather than based on cost of delay, which was calculated using server expenses, complexity of migration, frequency of change per application, and other factors—we’d have lost opportunities to turn expensive servers off gradually throughout the migration. As a result, HMRC would have paid for the infrastructure, unnecessarily, throughout the entire duration of the re-homing project.

Using cost of delay to determine a strategic priority level for each application, we were able to decommission servers throughout the lifecycle of the project. The result? Reduced spend on physical infrastructure, and more money saved, sooner.

What’s the cost of failing to calculate cost of delay?

The old saying suggests that ‘failing to prepare is preparing to fail’.

By neglecting due diligence and migrating without any underlying strategy for priority, you’ll only understand your missteps when it’s too late to correct them.

Perhaps you’ll lose customers. Perhaps you’ll continue to outlay on redundant infrastructure. In some cases, organisations have gone out of business as a direct result of prioritizing the wrong projects or initiatives.

Ultimately, the choice is yours. You can move forward with a migration before calculating cost of delay, but at what price? Unfortunately, only time will tell.

Contact us!

We hope you find this useful.

For more information about cloud migration or the HMRC project take a look at our HMRC case study.

If you’d like us to share our experience with you, please get in touch in the form below.

For many large-scale corporate and government organisations dealing with legacy applications, a ‘lift and shift’ seems like the ideal way to migrate from physical servers to the cloud.

A lift and shift can be faster and easier to complete than comparative migration approaches that involve re-writing or re-architecting applications.

In other words, for many senior IT professionals, it’s easy to see a lift and shift migration as the quickest way to the cloud.

In reality—as with most tools or approaches—there are specific scenarios where a lift and shift is the ideal way forward.

So, how do you determine whether a lift and shift is right for you? How can you be sure this approach will provide the most value for your organisation and customers?

Ask yourself these crucial questions and the answers will help to guide your approach.

Firstly, before we even consider a lift and shift—or any other migration approach— it’s worth broadly asking: Why?

’Why should we engage in a migration project? What do you hope to achieve?

It’s critical to establish clear understanding and strong alignment. When your team can clearly articulate the purpose of the migration project and the measures of success, we can better determine our approach as a collective.

There are many ways to formalise the ‘why’. In past projects, like a large-scale lift and shift of 55 sophisticated tax applications for a UK government entity we’ve used tools from product management practices. One common example is a value proposition canvas.

Imagine your Development and Operations teams are your ‘customers’. In a workshop, we should agree on a series of hypothesis statements:

After you’ve developed and agreed on some meaningful hypothesis statements, you’ll better understand your goals. And therefore, we can determine whether a lift and shift is the best way to help you achieve those goals.

So then, what is a lift and shift?

A lift and shift involves taking an existing application that resides on physical infrastructure and moving it to a new hosting environment. Typically, it’s shifting applications from physical servers to the cloud.

In contrast to other migration approaches—like rewriting or re-architecting—a lift and shift does not involve any changes to the applications. Nothing is altered or improved throughout the migration process, aside from how and where the applications are hosted.

Hence the name: you ‘pick up’ the legacy applications in their current form (lift) and simply move them to a new environment (shift).

Before engaging in a lift and shift, you need to ask yourself these questions:

1. Have we confirmed that customers actually use and appreciate the applications we intend to migrate?

There’s very little value in moving something that nobody uses.

Firstly, you need to determine: how many customers use each application on a daily basis? How many use the applications in peak periods?

We typically employ a mixture of tools like Cisco’s AppDynamics, Google Analytics and facilitated user research practices to identify two things:

• The number of customers engaging with each application
• The way in which they engage with those applications

Armed with this information, you can also determine whether specific applications are meeting customer needs, or whether those needs are able to be satisfied elsewhere.

For example, do customers avoid or ignore a specific application because it’s easier to visit the customer service desk instead? Or, do they avoid a certain application because they can achieve the same result in an easier way through another application?

With this information, you can start to meaningfully consider:

2. Which applications do we actually need to re-home? How should we move each application specifically?

Due to the lift and shift’s perceived reputation for being easier and more time efficient than other migration approaches, there’s a general misconception that everything should automatically re-home to the cloud as standard practice.

In reality, once you have quantitative and qualitative information about customer interactions with each application, you’re far better placed to decide:

1. Whether you spend more time rewriting specific applications to provide an improved customer experience as part of the rehoming process
2. Whether you migrate the application in a way that ensures it’s easy to provide a better customer experience in the future
3. Whether you consolidate features from one application into another app that resonates better with customers, based on usage data
4. Whether you decommission the application entirely, and save money on the cost associated with rehoming it at all

These answers will help you to determine the best approach for each individual application involved in the migration programme. Ultimately, we don’t necessarily need to migrate everything. Even if we do, we can adopt a mix of migration techniques within the one suite of works.

It may sound surprising, but there’s also no harm in completely descoping an application from a proposed lift and shift migration.

If an application is old but working well, is robust enough to perform over time, and the maintenance or physical infrastructure associated with supporting that app is not going to become cost-prohibitive, there’s no need to fix something that isn’t broken.

3. Will we have an order of magnitude in projected operational cost savings once the migration is complete? Are we sure those savings will materialise?

Broadly speaking, there are three primary motivations for a lift and shift migration:

1. A desire to migrate to the cloud in general
2. A desire to make it easier to support applications in the future
3. A desire to save on infrastructure costs.

While a successful lift and shift will always deliver on the first two objectives, the third isn’t necessarily guaranteed.

If you don’t create significant savings on your infrastructure—and equally sizable reductions in general costs or time required to release future changes—the cost of a lift and shift can actually outweigh the savings associated with the move.

You need to carefully weigh up the entire cost of the migration program and compare it with the estimated savings you’ll recoup on completion.

Remember, take a holistic approach to calculating your prospective cost savings; total savings are often far greater than the reduction of spend on physical infrastructure. Try to factor for the benefits you’ll experience through:

— Eliminating the cost of any licensed platforms
— Eliminating the cost of support via third party suppliers
— Reducing ‘cost of delay’ by more rapidly releasing features and updates to support your customers

4. How do we ascertain the prospective cost of what needs to be moved and compare it with the projected value we will gain? How do we prioritise what moves first?

We often use an effort-versus-value matrix.

It’s an approach our team used particularly effectively while re-homing 55 complex legacy tax applications from physical servers to the cloud.

For each application involved in your project, ask yourself: What is the quantifiable effort associated with a shift?

Critically, you should base all estimated effort on the assumption that each app is the first one being moved. Why? Because the first application you migrate is always the most time-consuming and technically challenging. In this scenario, pessimistic estimations are typically more accurate than optimistic ones; any effort you estimate that isn’t required is ultimately a benefit.

Then look at the value of each application—what will you get out of that specific migration? In our example, we prioritised an application with multiple integration points and constant high volumes of user traffic. We prioritise and create a roadmap, and use that roadmap to plot when we can see value.

By completing the more complex migrations first, you realise the majority of the value. That’s because you typically solve the most sophisticated technical challenges early on and pave the way for those learnings to apply to all subsequent—and therefore smoother—app migrations.

From there, you can re-evaluate whether the effort of moving particular applications matches the value of the migration. At that point though, you can also reduce estimations of effort based on the accumulation of knowledge being leveraged from the earlier, more complicated migrations.

As the perceived effort of migrating each app is reduced, so is the value.

Ultimately, you’ll reach a point where the effort outweighs the value. That in itself is another clear signifier to ask once more: do we need to move everything as part of this migration?

In conclusion

While moving everything to the cloud may seem advantageous, it’s worth stepping back to consider your organisational goals, both long and short term.

Take the time to ask yourself some key questions, establish meaningful answers, and you may identify opportunities to save money in the long run by leaving certain applications as they are.

By all means, turn off any on-premise infrastructure that will save money in the long run, via total cost of ownership.

Otherwise, don’t be afraid to leave things as they are; especially if they’re still running and meeting a need, and particularly if you don’t have a cost-prohibitive long-term datacentre contract.

Your priority shouldn’t always be to get to the cloud as quickly as possible, because the grass isn’t always greener.

It is always greener, however, when you manage and consolidate those things that unlock new revenue streams and unearth cost savings. By asking yourself the above key questions, you’re better placed to identify exactly what those things are.

Contact us!

We hope you find this useful. For more information about lift and shift migration or the HMRC project take a look at our HMRC case study.

If you’d like us to share our experience with you, please get in touch in the form below.