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.