How to create a digital roadmap

To create a digital roadmap, start from what the business is trying to achieve, list the systems and processes you already have and the condition they are in, identify the gaps and the dates you cannot move, and then choose a small number of pieces of work and put them in order. The result is a page or two that says what you will change over the next one to three years, why and who is responsible. It is not a shopping list of technology, and it does not need a consultant or a workshop to produce a first version.

What a digital roadmap is

A digital roadmap is a plan for how the organisation’s software, data and digital processes will change. For a company of 10 to 500 people it usually covers:

• the business objectives the plan serves;
• the systems in use today and what will happen to each;
• a short list of initiatives, grouped by when they will happen;
• a rough cost band and an owner for each;
• the dates that are fixed by something outside your control.

The useful ones are short, held by a named person and revised regularly. The ones that fail are long documents written once and filed.

Step 1: start from what the business is trying to do

Technology decisions made without an objective tend to be justified afterwards. Begin with three or four objectives the leadership already agrees on, stated so that you could tell whether they had been met:

• reduce the time from order to invoice;
• take on more customers without adding administrative staff;
• open a second site;
• give customers a way to see their own orders;
• pass a customer’s or insurer’s security questionnaire.

Then ask of each one what currently stands in the way. The answers are where the roadmap comes from. It is worth asking customers and front-line staff as well as managers, because they see the delays and the workarounds directly.

Step 2: take stock of what you have

List every system the business depends on. Include the ones nobody thinks of as systems: the spreadsheet that prices every quotation, the Access database in the accounts office, the shared mailbox that acts as an order queue. For each, record:

• what it does and who relies on it;
• who looks after it, and whether anyone could change it tomorrow if asked;
• what it runs on, including version numbers;
• where its data is held and how it is backed up;
• what other systems it exchanges data with, and how.

This inventory is often the most valuable result of the whole exercise. It commonly shows that a critical process depends on one person, or on software its vendor has stopped supporting. If nobody is sure what a server is running, our free end-of-support check lists it for you.

Step 3: find the gaps and the fixed dates

With objectives and an inventory side by side, the gaps are usually plain. They fall into a few kinds.

Manual work between systems. Staff re-typing data from one system into another, or exporting to a spreadsheet to produce a report. Where a spreadsheet has become the system, see replacing spreadsheets; where two systems each hold half the picture, see systems that do not talk to each other.

Systems that are holding the business back. For each one, decide whether to keep it as it is, modernise it in stages or replace it. Age alone is not the test. Our maintain, modernise or replace check asks ten questions and gives a recommendation.

Things the business cannot do at all. A customer portal, online ordering, reporting that does not take a week. For each, check whether a packaged product would do before assuming it has to be built; bespoke software vs off-the-shelf software explains how to test the fit.

Fixed dates. Vendor support dates are set by others and belong on the roadmap whether or not they match your priorities. As this article is updated in October 2026, Office 2021 reaches the end of support on 13 October 2026, .NET 8 and .NET 9 both on 10 November 2026, and Windows Server 2016 on 12 January 2027. SQL Server 2016 stopped receiving security fixes in July 2026 unless you pay for extended updates. Contract renewals, an office move and regulatory deadlines belong in the same list.

Artificial intelligence should be treated like any other candidate. If a specific, costed problem would be solved by it, it goes on the list with the others. “We need an AI strategy” is not an initiative.

Step 4: choose a few initiatives and put them in order

You will now have more candidates than you can afford or absorb. Sort them using four questions:

• How much is it worth, in the terms of the objectives from step 1?
• How big is it, roughly: weeks, months or more than a year?
• Is there a date attached?
• Does anything else depend on it being done first?

Work with a fixed date goes in at the latest point that still meets the date with a margin. Among the rest, favour small pieces of work with a clear payoff, particularly early on, because they build confidence in the plan. Resist the urge to run everything at once. The limit is seldom money alone; it is the attention of the few people in your business who have to specify, test and adopt each change.

Then lay the result out by time horizon. Near-term items should be specific. Later ones can be vaguer, because you will know more by the time you reach them. An illustrative example:

Add a cost band to each line, not a precise figure. Precise figures come from scoping each initiative when its turn arrives. Include a line for looking after what you already run: support, security updates and small changes continue alongside the new work and need a budget of their own.

When the draft is ready it will need approval. Tips for gathering internal support for your software project covers how to present it.

Step 5: review it every quarter

A roadmap is out of date within months if nobody maintains it. Put a review in the calendar each quarter, and at each one ask what was finished and whether it had the effect intended, what has changed in the business, and whether the next item is still the right one. Move items, drop them and add new ones freely. The value is in having one agreed, current picture.

The common mistakes are easy to list. Starting from a technology instead of an objective. Listing fifteen initiatives with no order. Planning new systems while ignoring the condition of the existing ones. Leaving items without an owner. And treating the document as finished.

If you do one thing this week, make the inventory in step 2: one page, every system, with its version, its owner and its support date. Most of the roadmap follows from reading that page alongside your objectives.