A cloud strategy sets out which workloads an organization will move to the cloud, in what order and on which platforms, and how security and cost will be controlled along the way. It is owned by the head of infrastructure and agreed with the chief information officer, the finance director, the security lead and the engineering teams whose applications will move.
A complete cloud strategy for a fictional organization: freight brokerage arranging 600,000 truckload and less-than-truckload shipments a year from its own data center.
| Organization | Freight brokerage arranging 600,000 truckload and less-than-truckload shipments a year from its own data center (900 staff) |
|---|---|
| Ambition | Close the owned data center by the end of 2028 and run the transportation management system across two cloud regions, with recovery measured in minutes and spend owned by each product team. |
| Horizon | 2 years |
The brokerage books about 2,400 loads a day through a transportation management system built in-house, running on 410 virtual machines in a data center at head office with a recovery site in a colocation facility. Storage and compute hardware reach end of support in early 2029, and a like-for-like refresh is quoted at $3.8M. Two failures last year, a cooling fault and a storage controller, took the system down for 11 hours; each business hour offline puts about $65,000 of margin at risk. The last full recovery test took 26 hours against a four-hour target. Average processor utilization is 22%, and a new environment takes 19 days to provision.
Challenges| Drivers | Resilience comes first: 11 hours of downtime in a year and a recovery site that fails its test. Second, avoiding a $3.8M hardware refresh. Third, capacity that follows freight volume, which swings 40% between produce season and the winter low. Fourth, letting 60 developers create environments without a 19-day wait. |
|---|---|
| Constraints | No cutovers of booking, tracking or EDI systems during produce season, April to July, or the last two weeks of any quarter. EDI partners must be moved in groups with parallel running. Database licenses are tied to physical cores until renewal in March 2028. Shipper contracts require an annual independent security controls report with no gap in coverage. |
| Success looks like | The owned data center is closed and its lease surrendered by Q4 2028. The transportation management system fails over between regions in under 30 minutes, tested twice a year. Steady-state run cost is at or below today's $5.2M, and every dollar has an owner. |
| Workload | Approach | Complexity | Wave |
|---|---|---|---|
| Development and test environments | Rehost, then rebuild from code | Low | Wave 1, H1 2027 |
| Document imaging archive, 40 TB of bills of lading and delivery receipts | Replatform to object storage | Low | Wave 1, H1 2027 |
| File shares and telephony | Replace with software as a service | Low | Wave 1, H1 2027 |
| Data warehouse and reporting | Replatform to a managed warehouse | Medium | Wave 2, H2 2027 |
| Carrier and shipper portals, tracking APIs | Replatform to containers | Medium | Wave 2, H2 2027 |
| EDI gateway, 340 trading partners | Rehost, partners cut over in groups of 50 | High | Wave 3, Nov 2027 to Mar 2028 |
| Transportation management system and database | Rehost application, replatform database to a managed service | High | Wave 4, Q3 2028 |
| Providers | One hyperscale provider for all infrastructure, using two regions in the same country. Commodity functions such as email, telephony and file sharing go to software as a service. The colocation facility is kept on a reduced footprint for the accounting system and the network edge until 2029. |
|---|---|
| Landing zone | Separate accounts for production, non-production, shared services and security, under one organization with preventive policies. A hub network in each region with two private circuits from head office and the colocation site. Everything is deployed from version-controlled code through a pipeline; console changes in production are blocked. Logs from every account flow to a central, read-only store. |
| Operating model | A platform team of eight owns the landing zone, pipelines, shared services and cost reporting. Application teams own what they deploy and are on call for it. A managed service partner provides 24-hour monitoring and first response for the first 12 months, with a planned handover as internal engineers are certified. |
| Identity | Single sign-on from the corporate directory with MFA for every person. No shared or long-lived access keys: workloads use short-lived roles. Administrative access is requested per task, approved, time-limited and recorded. |
|---|---|
| Data protection | Shipper rates, carrier bank details and driver personal data are classified as restricted and tagged. All storage and databases are encrypted with keys we control, and traffic is encrypted in transit. Backups are immutable, copied to the second region and restored in a test each month. |
| Compliance | The annual security controls report continues without a gap: controls are mapped to the new platform before wave 2, and evidence is collected automatically from configuration rules. Card payments from shippers are taken by the payment provider, so no card data enters our environment. An external penetration test is run after each wave. |
| Budget | Infrastructure run cost is $5.2M a year today, including the data center, the colocation site, hardware depreciation and licenses. It peaks at $6.9M in 2028 while both environments run, then settles at a target of $4.7M in 2029. One-off migration cost is $2.9M for partner services, training and parallel running, against the $3.8M refresh avoided. |
|---|---|
| Cost ownership | Every resource carries tags for product, environment and cost center, enforced at deployment. Engineering managers receive a monthly statement for their products and review it with finance. Showback starts with wave 1; chargeback to product budgets starts in 2028. |
| Optimization rules | Non-production environments shut down outside working hours. Rightsizing recommendations are reviewed monthly and acted on within 30 days. After three months of stable usage, 60% to 70% of steady compute is covered by one-year commitments. Budget alerts fire at 80% of forecast, and untagged non-production resources are stopped after 14 days. |
Priorities and measures
Hardware support ends in early 2029 and the refresh decision is due by mid 2028. Every workload still on site by then weakens the case for avoiding $3.8M.
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| Virtual machines remaining in the owned data centerMilestones: 320 machines by Q2 2027 · 220 machines by Q4 2027 · 110 machines by Q2 2028 | 410 machines | 0 machines | Q4 2028 |
| Production workloads running in the cloudMilestones: 45% by Q4 2027 · 70% by Q2 2028 | 12% | 95% | Q4 2028 |
Eleven hours of downtime and a 26-hour recovery test are the reasons the board approved this program. A migration that reproduces a single-site design in the cloud would not fix either.
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| Unplanned downtime of the transportation management system per yearMilestones: 8 hours by Q4 2027 | 11 hours | 1 hours | Q4 2028 |
| Recovery time achieved in the latest full failover testMilestones: 480 minutes by Q4 2027 | 1,560 minutes | 30 minutes | Q4 2028 |
Nineteen days to provision an environment means features queue behind infrastructure. The migration only pays back fully if engineering can release more often once it is done.
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| Time to provision a new environmentMilestones: 5 days by Q2 2027 | 19 days | 1 days | Q4 2027 |
| Infrastructure deployed from version-controlled codeMilestones: 50% by Q4 2027 | 5% | 90% | Q4 2028 |
| Production releases of the transportation management system per monthMilestones: 4 releases by Q4 2027 | 2 releases | 8 releases | Q4 2028 |
Costs peak at $6.9M during parallel running. Without tagging and forecasts from the first month, nobody can show the spend falling back to $4.7M.
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| Cloud spend allocated to a product owner through tagsMilestones: 80% by Q2 2027 | 40% | 98% | Q4 2027 |
| Monthly variance between forecast and actual cloud spendMilestones: 12% by Q4 2027 | 23% | 5% | Q4 2028 |
| Average processor utilization of production computeMilestones: 32% by Q4 2027 | 22% | 50% | Q4 2028 |
The same structure with a prompt in every field. Copy it, or download it as a Word or Excel file.
| Organization | [Describe your organization in a few words, with its size] |
|---|---|
| Ambition | [One sentence on where you want to be at the end of the plan] |
| Horizon | [How long the plan runs, for example 12 months] |
[Where things stand today: the facts that make this strategy necessary]
Challenges| Drivers | [Your drivers] |
|---|---|
| Constraints | [Your constraints] |
| Success looks like | [Your success looks like] |
| Workload | Approach | Complexity | Wave |
|---|---|---|---|
| [Workload] | [Approach] | [Complexity] | [Wave] |
| [Workload] | [Approach] | [Complexity] | [Wave] |
| [Workload] | [Approach] | [Complexity] | [Wave] |
| Providers | [Your providers] |
|---|---|
| Landing zone | [Your landing zone] |
| Operating model | [Your operating model] |
| Identity | [Your identity] |
|---|---|
| Data protection | [Your data protection] |
| Compliance | [Your compliance] |
| Budget | [Your budget] |
|---|---|
| Cost ownership | [Your cost ownership] |
| Optimization rules | [Your optimization rules] |
Priorities and measures
[Why this priority matters now, in one or two sentences]
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
[Why this priority matters now, in one or two sentences]
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
[Why this priority matters now, in one or two sentences]
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
[Why this priority matters now, in one or two sentences]
| Outcome | Baseline | Target | Due |
|---|---|---|---|
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
| [Metric you will track] | [Where it is today] | [Where it should be] | [When] |
Write the drivers in order of importance and attach a date or a number to each. A lease expiry or hardware refresh sets the real deadline.
Group applications into workloads and choose one approach for each: rehost, replatform, refactor, replace, retain or retire. Be honest about what will stay behind.
Order the waves by risk. Start with workloads that teach the team the platform and cannot stop the business, and move the core system last.
Finish the landing zone, identity and logging before the first production workload. Retrofitting controls across live accounts takes far longer.
Model the double-running period explicitly. Costs rise before they fall, and finance should see the peak in advance.
Assign cost ownership to the teams that deploy resources and decide the tagging standard before wave 1.
A plan only works if it is reviewed on a rhythm. This is the cadence the example assumes.
| Check-in | Outcome owners update progress and confidence weekly. |
|---|---|
| Review | Priority owners review outcomes and unblock initiatives monthly. |
| Reset | Leadership revisits priorities and targets quarterly. |
Tability keeps this cadence for you. Each priority becomes an objective, each outcome a key result with its baseline and target, and each initiative a tracked task. Owners get a check-in reminder and the plan shows what is on track.
Track this plan in TabilityStill comparing tools? See the 10 best strategy software tools.
It should include the business drivers and constraints, an assessment of each workload with its migration approach and wave, the chosen platform and operating model, the security and compliance controls, and how cost will be forecast and owned. Add measurable outcomes for migration progress, reliability, delivery speed and spend.
The cloud strategy explains why the organization is moving, which workloads go where and how the cloud will be run and paid for. The migration plan is the detailed schedule of cutovers that follows from it. Without the strategy, a migration plan tends to move everything as it is and reproduce the old problems.
It depends on the deadline and the application. Rehosting is faster and suits a fixed date such as a data center exit. Refactoring gives more benefit but takes longer and carries more risk. A common approach is to rehost the application, replatform the database to a managed service, and refactor selectively afterward.
For a mid-size company with a few hundred servers, plan on 18 to 24 months from decision to closing the facility. The first three to six months go on the landing zone, security controls and training. Core systems with many external integrations usually move last and take the longest to cut over.
Not automatically. Costs usually rise during the period when both environments run, and a like-for-like move of oversized servers can cost more than the data center did. Savings come from avoided hardware refreshes, rightsizing, shutting down idle environments and committing to steady usage. Model the peak and the steady state separately.
A product strategy states who the product is for, which problems it will solve first, and why customers will choose it over the alternatives.
An IT strategy sets out which technology investments an organization will make over the next two to three years, in what order, and how they support its business goals.
An AI strategy sets out where an organization will apply artificial intelligence first, the data, platforms and skills those uses depend on, and the rules that keep them safe and lawful.
Cloud strategy template
Horizon: 2 years
4 priorities · 10 outcomes
Targets are illustrative. Adapt them to your baseline before you start.