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.