IT management
IT roadmap
An IT roadmap is a time-based plan of the initiatives, milestones and dependencies that take an organization's technology from today's state to its target.
An IT roadmap exists so that the people funding technology work and the people doing it look at the same picture of what happens when. It is the time dimension of enterprise architecture: a target architecture turned into a sequence that can be argued about, budgeted and later checked.
What does an IT roadmap include?
- Lanes. Areas of IT such as platform, applications, security and data, or business capabilities, or teams. Lanes let a reader find their part.
- A timeline. Quarters are the usual unit. Months are too fine for a multi-year plan and years too coarse to show order.
- Initiatives. The bars. Each has an owner, a start, an end and a short name a stakeholder recognizes.
- Milestones. The points where something becomes true: an audit passed, a data center exited, a system retired, an AI governance review gate cleared. They are what stakeholders remember.
- Dependencies. Arrows showing that one initiative cannot start or finish until another does. These are the roadmap’s most useful content and the most often left out.
- A today marker and a note on confidence. Where the organization is now, and a reminder that later quarters are less certain than nearer ones.
What are the types of IT roadmap?
Technology roadmap
Organized by platform and infrastructure: cloud migration, network, identity, end-user computing. It answers “what will we run on?” and is the natural home for the end-of-support dates and refresh cycles that come from IT asset management.
Application roadmap
Organized by application or domain, with each application’s planned fate: invest, keep, consolidate or retire. It is the time dimension of application portfolio management and application rationalization.
Capability-based roadmap
Organized by business capability, with the initiatives that improve each one. It is the easiest for business stakeholders to read, because the lanes are their language, and it keeps the technology work tied to a business capability map.
Most organizations keep one roadmap in one of these forms and produce the others as views of it, rather than three documents that drift apart.
How do you read an IT roadmap?
The diagram at the top of this page is a technology roadmap for the retail company whose current and future state appear elsewhere in this glossary.
- Platform lane. A cloud landing zone is in progress now and finishes in Q2 2027. A Kubernetes platform follows in the second half. The data center exit is a milestone in Q2 2028.
- Applications lane. The order service starts in Q3 2027, and a dashed arrow from the landing zone shows that it cannot start before the landing zone is done. CRM consolidation runs through the first half of 2028.
- Security lane. Single sign-on completes in the first half of 2027, a SOC 2 audit lands at the end of Q4 and zero trust access runs across the whole period.
- Data lane. The cloud data platform runs from Q2 to Q4 2027 and the warehouse decommission depends on it.
- The long dependency. The data center exit depends on the order service, drawn as an arrow from the end of that bar up into the platform lane. If the order service slips, so does the exit.
How do you build an IT roadmap from current and future state?
- Draw the current state honestly. From the CMDB, cloud accounts and the application portfolio, not from memory. Mark the technical debt that constrains what can move.
- Agree the target state. Two to three years out, approved by the architecture review board, with every current system marked keep, retire, replace or consolidate.
- Run the gap analysis. Each difference between the two states becomes an initiative with a rough size.
- Find the dependencies. For each initiative ask what has to exist first. Landing zone before workloads, data platform before warehouse decommission, order service before data center exit.
- Add the fixed dates. Contract ends, end-of-support dates, audits and regulatory deadlines are the milestones that do not move.
- Sequence within capacity. Teams can run a limited number of initiatives at once. Lay the bars out so each lane’s load is plausible and push the rest right.
- Publish, then review quarterly. Move the today marker, mark what landed, redraw what slipped and record why.
How do you keep an IT roadmap honest?
- Dates come from owners, not from the roadmap. An initiative’s end date is whatever its owner commits to. If the roadmap says Q3 and the owner says Q1 next year, the roadmap is wrong.
- Show slippage rather than hiding it. Keep a copy of each published version. The difference between versions is the organization’s real delivery rate and the best input to the next version.
- Fade the future. Draw committed, planned and directional initiatives differently, so a reader can tell a promise from an aim.
- Tie every bar to the gap. An initiative that does not close a difference between current and target state is either missing from the target or does not belong on the roadmap.
What are common IT roadmap mistakes?
- A list of projects with dates. Without lanes, dependencies and a target it comes from, a roadmap is a Gantt chart with less detail.
- No dependencies. The arrows are what make slippage visible. Leaving them out makes every delay a surprise.
- Equal confidence everywhere. Drawing Q2 2028 as firmly as next quarter guarantees the roadmap is wrong and then read as broken.
- Too much on it. A roadmap with sixty bars is not read. Keep the initiatives that matter to the audience and link to the detail.
What tools help with IT roadmaps?
- Roadmapping and portfolio tools. Purpose-built products and the roadmap views in work-tracking platforms keep initiatives, owners and dates in a database and draw the swimlanes from it. They suit a roadmap with many contributors.
- Slides and spreadsheets. The most common form and the easiest to share with executives. They go out of date the moment an initiative moves and have no notion of dependency.
- AI diagramming tools. Tools like Eraser draw the current state the roadmap starts from, as maps generated from a CMDB and cloud accounts, so the roadmap begins from what actually runs. See Eraser for enterprise architects.
Frequently asked questions
-
What is the difference between an IT roadmap and an IT strategy?
The strategy says where technology should take the business and why: which capabilities to build, which platforms to standardize on, what to stop doing. The roadmap says when and in what order, as initiatives with dates, dependencies and milestones. A strategy without a roadmap stays an intention. A roadmap without a strategy is a project list.
-
How far ahead should an IT roadmap go?
Most cover one to three years, with detail that fades with distance. The next two quarters hold committed initiatives with owners and dates. The quarters after that hold planned initiatives that may move. Anything beyond a year is directional and should be drawn that way, or readers will treat it as a promise.
-
What is the difference between an IT roadmap and a project plan?
A project plan schedules the tasks inside one initiative, down to weeks and people. A roadmap sits above that, showing how initiatives across the whole IT estate line up over quarters and where they depend on each other. The roadmap decides which projects exist. The project plans decide how each one gets done.
-
Who owns the IT roadmap?
Usually the CIO or CTO owns it, enterprise architecture maintains it and an architecture review board or portfolio board approves changes. Each initiative on the roadmap has its own owner. What matters most is that one named group updates it on a schedule, because a roadmap nobody maintains quickly becomes a record of what was once hoped.
