Cloud Preparation Plan

A cloud adoption preparation guide for public sector organisations.

This document is part of a collection

Rationalise your digital estate

What is a digital estate?

The term digital estate refers to all of the digital assets you use to deliver services to your organisation and your customers. Examples of digital asset include applications, servers and data.

Why rationalise your digital estate?

You should assess and rationalise your digital estate and assets before creating your cloud strategy because it:

  • helps you to uncover and communicate business challenges and constraints resulting from technical sources early in the process
  • helps to define a timeline for adopting cloud services, particularly for organisations operating on a set timeline due to contract, facility or hardware asset lifecycle events
  • provides a high-level starting point from which to begin your Cloud Adoption Plan (CAP).

For many organisations, their digital estate is at least a partially unknown entity. For these organisations, the disruption that adopting cloud services causes can act as a catalyst for organisational and operational improvement because it requires you to review the business from top to bottom. It also encourages you to look for strategic solutions to long-standing challenges, based on new capabilities introduced by public cloud services.


Work through these steps to help you discover, capture and perform an initial rationalisation of your estate.

Step 1 – Understand our approach to incrementally assessing your digital estate

Step 2 – Identify sources of information

Step 3 – Capture your digital estate information

Step 4 – Understand our approach to dealing with legacy assets

Step 5 – Perform an initial rationalisation of your digital estate


Use these templates to capture your information:

Include performance summary by workload profile.

Step 1 - Incrementally assessing your estate

Performing a deep assessment of your digital estate at the beginning of your cloud adoption journey is not recommended because it requires a significant investment in time and effort, and becomes a blocker to cloud adoption.

Therefore, to build and maintain momentum for your cloud programme, you should start by discovering, documenting and rationalising your estate at a higher-level. This will provide enough information to support your cloud strategy and rationalisation efforts, without over-burdening your internal teams. It is important to build senior stakeholder buy-in before requesting significant investment. This means you should start by demonstrating business value and alignment with business outcomes to encourage stakeholder engagement with the programme.

We recommend you capture enough information on workloads to:

  • identify the service owner
  • create a dependency map for the workload
  • understand service / asset usage
  • understand asset lifecycle(s)
  • understand the performance profile of workloads
  • determine business criticality
  • record data classifcation.

This phase of your cloud journey will likely be completed by a small number of individuals, usually backed by limited senior stakeholder support and investment in time and budget. Therefore, to build momentum, the effort must generate business value and tangible proress to obtain stakeholder buy-in and investment.

Note: assessing workloads at a higher-level will not provide all of the information you need to make informed decisions later. The focus at this stage is to understand your digital estate with a sufficient degree of accuracy to allow initial rationalisation, but naturally relies on some assumptions. Workloads will be assessed again in greater detail later, during the cloud migration stage.

Step 2 - Identify sources of information

Before you start the process of discovering your digital estate, you should identify sources of information within your organisation that may hold workload and digital asset information. These sources of information are often also the service owners – though this is not always the case.

Typical sources of information for assets are:

  • IT teams: infrastructure, application and software development
  • catalogues: application, service and infrastructure catalogues
  • other departments: areas of the business with specific services, such as Human Resources and Finance.

Some organisations will already have a detailed understanding of their digital estate, which will reduce the time needed to complete this phase of the plan. Others may hold limited information and will need to complete the exercise in full.

In either case, the information gathered must be accurate enough to ensure your understanding of your estate – and your rationalisation effort – are based on a sound understanding of your current position. Use service owners to verify your understanding of your workloads and digital assets.

Step 3 - Capturing your digital estate information

When performing the initial discovery of your digital estate, you should capture enough information to allow you to perform an initial rationalisation.

Assets to capture include:

  • applications
  • services
  • hardware
  • virtual machines
  • software.

Information to capture includes:

  • identify the service owner
  • a dependency map for the workload
  • service / asset usage
  • asset lifecycle(s) phase
  • performance profile
  • business criticality
  • data classifcation.
Note: data is also a digital asset, but the information you should capture and how you should interpret are different. Data is considered later in the Cloud Preparation Plan.

The information you need to capture to support rationalisation will vary by asset type.  These templates provide guidance on what you information should capture.

It is unusual to find previously unknown digital assets within a digital estate, but is not unusual to find legacy assets that have no defined owner or supporting documentation. If you encounter such assets, follow our advice on [dealing with legacy assets.]

Every workload and digital asset must have an owner. Almost all cloud-hosted workloads incur costs, and service owners are responsible for managing, optimising and reporting on costs.

Step 4 - Dealing with legacy assets

Many organisations have legacy digital assets that have no responsible party or service owner. This is most often the case for legacy applications or hardware.

The discovery of these assets will take longer, but should not be skipped. To build your understanding of the asset, you should:

  • review documentation (if any exists)
  • conduct interviews with adjacent teams to locate stakeholders (who notices first when the asset is unavailable?)
  • assess usage by reviewing logs and performance metrics.

If you genuinely cannot determine who owns an asset, allocate an individual or team from the most relevant business area (for example, hardware to infrastructure team, software to the development team).

Dealing with legacy assets can be intimidating because the risks and consequences of affecting their operation are hard to quantify. However, you must be courageous when dealing with legacy. Make the best informed decision you can with the information you have.

Adopting cloud services means adopting new ways of operating and approaching challenges. By dealing with legacy assets decisively, you can shift your organisation’s mind set from reactive to proactive, sending a clear signal that positive change is occurring and long-standing challenges are being overcome.

Step 5 - Initial rationalisation of your digital estate

Once you have completed the initial discovery of your workloads and digital estate, the next step is to review your assets and allocate an initial rationalisation action.

The industry-standard approach to this process is to assign one of the following actions to your workload or asset.

Action Description
Retire If an asset or workload is redundant you should retire it. Assets such as servers can be marked as 'retire' if the hosted workload has an associated action.

This is often described as 'lift and shift'. Rehosting is the least preferred rationalisation action, as it results in the fewest benefits associated with cloud adoption.

However, organisations with no alternative - perhaps due to a datacentre closure or hosting contract expiry - may need to rehost as a tactical response in the short-term. This should be avoided whenever possible.

Refactor An application can be slightly refactored to enable it to run on Platform-as-a-Service offerings, resulting in operational and development efficiencies.
Rearchitect An application can be rearchitected to make it compatible with public cloud services.
Rebuild Legacy applications that are too expensive to adapt to cloud delivery (in terms of time and cost), should be rebuilt as cloud native applications (where possible).
Replace An application can be replaced with an off-the-shelf Software-as-a-Service offering. This is often the most desirable often and realises the greater number of benefits. However, while there are a vast array of SaaS services, some workloads are unsuitable.

The purpose of your cloud adoption programme and the government's cloud first policy is not to immediately assess and migrate all workloads to public cloud services. Workloads should be migrated where there is a pressing need or tangible benefit.

It is acceptable to maintain supported workloads on-premises and to rationalise periodically in line with shifting priorities.

It is important to understand that the action you allocate will be influenced by more than simply the most desirable target state and service model for a particular service or workload.

These influences include:

  • critical business drivers (data centre closures, hosting contract expiry, etc.)
  • skills capacity and availability
  • migration sequencing (resulting from your dependency maps)
  • budget constraints.

 For example, whilst you may intend to re-architect a business-critical application to run natively in the cloud, if you need to evacuate your datacentre you may need to re-host it in the short term.



Telephone: 0300 244 4000


Cloud First
Digital Transformation Division
Area 1H South
Victoria Quay

Back to top