A cloud plan built from your application list, not a slide of logos.
Cloud plans tend to stall on the long tail. There are applications nobody owns and license terms nobody can explain, and the data center contract ends before anyone is ready. We start with your inventory and write a plan each application owner can sign.
Application inventoryCMDB · owners · interviewsCurrent run costshardware · licenses · contractsFixed dateslease end · end of support
02 · Assessment
Portfolio assessmentrehost · replatform · retire
03 · Design
Landing zone designaccounts · network · guardrailsIdentity modelworkforce SSO · workload federationCost baselineFinOps model · tagging
04 · Output
Sequenced roadmapwaves · owners · decisions
TerraformMicrosoft Entra IDOktaHashiCorp Vault
in short·15-second read
Cloud strategy decides which workloads move to which cloud, in what order, how, and under what guardrails.
Cohash builds that plan from your real application inventory. We give each workload a disposition, design the landing zone and the identity model for people and workloads, set a cost baseline, and map the result to the AWS, Azure or Google Cloud architecture framework your reviewers already use.
you probably need this if
Leadership wants a cloud plan but the application inventory is years out of date.
Teams picked different clouds on their own and nobody decided on purpose.
Every new account request stalls in security review. There's no agreed landing zone for them to approve.
terms on this pageLanding zonedefinitionThe base cloud setup that workloads move into: accounts, network layout, identity and security rules, built before migration waves start.explained in a field note →FinOpsdefinitionTreating cloud spend as an engineering problem. Resources get tagged, costs land with the team that owns them, and someone acts on them while the numbers are still fresh.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Cloud Strategy, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · cloud strategy3 open
openLeadership wants a cloud plan but the application inventory is years out of date.
recurringTeams picked different clouds on their own and nobody decided on purpose.
blockedEvery new account request stalls in security review. There's no agreed landing zone for them to approve.
exposure
Portfolio assessmentLanding zone designCloud identity modelCost baseline and FinOps modelDeadline-driven sequencing
startrehearsehandover
Inventory
Assess
Design
Roadmap
we are here
ready to hand over
Every application has an owner and a disposition, including the ones nobody wanted.
The business case shows license cost per workload next to infrastructure cost, so the…
Security approves a pattern instead of every request.
Application portfolio with a disposition and owner per workload
chapter 01 · where it hurts
Why teams reach out
Leadership wants a cloud plan but the application inventory is years out of date.
Teams picked different clouds on their own and nobody decided on purpose.
Every new account request stalls in security review. There's no agreed landing zone for them to approve.
chapter 02 · what we change
How we solve it
Portfolio assessment
Landing zone design
Cloud identity model
Cost baseline and FinOps model
Deadline-driven sequencing
chapter 03 · how it runs
Our approach
Inventory
Assess
Design
Roadmap
chapter 04 · where you end up
What changes
Every application has an owner and a disposition, including the ones nobody wanted.
The business case shows license cost per workload next to infrastructure cost, so the cloud decision rests on the numbers that actually move.
Security approves a pattern instead of every request.
Application portfolio with a disposition and owner per workload
what we do
Where we spend the hours
5 areas of work, each one done by an engineer who has run it in production.
Each application scored on business value, technical condition, dependencies and license terms, then given a disposition and a named owner. Unowned applications get flagged, not quietly moved.
We design the account or subscription hierarchy, the network topology, central logging, and policy guardrails like service control policies or Azure Policy. It's all written as Terraform, so it gets reviewed like any other code.
People sign in through your identity provider, whether Entra ID or Okta, with no local IAM users. Workloads authenticate with federated, short-lived tokens. We settle this before the first workload lands, because retrofitting it later means touching every application twice.
We measure the current run rate and estimate a target per workload. Then we agree a commitment strategy, plus tagging rules that make showback or chargeback possible from the first month.
Waves ordered around hard dates: hardware refreshes, data center exits and vendor end of support. Windows Server 2016 leaves extended support in January 2027, and .NET 8 support ends on 10 November 2026.
capability 01 / 05in production
Portfolio assessment
Each application scored on business value, technical condition, dependencies and license terms, then given a disposition and a named owner. Unowned applications get flagged, not quietly moved.
We design the account or subscription hierarchy, the network topology, central logging, and policy guardrails like service control policies or Azure Policy. It's all written as Terraform, so it gets reviewed like any other code.
People sign in through your identity provider, whether Entra ID or Okta, with no local IAM users. Workloads authenticate with federated, short-lived tokens. We settle this before the first workload lands, because retrofitting it later means touching every application twice.
We measure the current run rate and estimate a target per workload. Then we agree a commitment strategy, plus tagging rules that make showback or chargeback possible from the first month.
Waves ordered around hard dates: hardware refreshes, data center exits and vendor end of support. Windows Server 2016 leaves extended support in January 2027, and .NET 8 support ends on 10 November 2026.
We pieced these together from Cloud Strategy situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Colocation contract ends on a fixed date and the CMDB is years stale
composite · not a client story
Beforethe situation
The colocation contract ends on a fixed date. There are 600 servers in the CMDB and closer to 900 according to discovery agents, and about a fifth of the applications have no named owner. Leadership wants a cloud plan within a quarter.
What we dothe work
Run discovery tooling alongside the CMDB export and reconcile the two lists. Interview owners of the applications that carry the most revenue or risk, give each one a disposition, and send unowned applications to a named executive for a retire-or-adopt call. Sequence waves backward from the contract end.
Afterwhere you end up
Every application has an owner and a disposition, including the ones nobody wanted. Leadership can see which waves fit before the contract ends and which need an extension or a retirement decision.
case file 02
Oracle and SQL Server licensing decides the business case
composite · not a client story
Beforethe situation
The portfolio leans on Oracle Database Enterprise Edition and SQL Server under Software Assurance. The only cost estimate so far came from a vendor calculator that leaves licensing out entirely.
What we dothe work
List each database with edition, core count and support contract. Price three paths per database: rehost on VMs with your own licenses, a managed service with license included, or a move to another engine. Bring in licensing specialists where the contract terms are unclear.
Afterwhere you end up
The business case shows license cost per workload next to infrastructure cost, so the cloud decision rests on the numbers that actually move. Database moves get their own waves and owners.
case file 03
Security reviews every new cloud account by hand
composite · not a client story
Beforethe situation
Teams wait weeks for each new cloud account because security reviews every request from scratch. There is no agreed account structure, no central log archive and no standard network pattern.
What we dothe work
Write the landing zone as a short design document plus Terraform modules covering the OU or management group hierarchy, a log archive account, hub networking and a baseline policy set. Security reviews the pattern once. After that, new accounts are requested through a pipeline that applies it.
Afterwhere you end up
Security approves a pattern instead of every request. New accounts arrive with logging, networking and guardrails in place, and exceptions follow a written path.
How a cloud strategy turns an inventory into a plan
Application and cost data feed a portfolio assessment that gives each workload a disposition. Those decisions shape the landing zone, the identity model and the cost baseline, which together become the sequenced roadmap.
We don't start a step until the last one has produced something you can check.
step 01
Inventory
Pull from your CMDB, discovery tooling and billing data. Then interview the application owners, because those sources always have gaps.
step 02
Assess
Workloads scored and grouped by dependency, license constraint and risk, with the scoring rules written down so they can be challenged.
step 03
Design
Landing zone, identity model, network and guardrails, agreed with security, networking and the platform team.
step 04
Roadmap
Migration waves, a business case per wave and a decision log your team can revisit when circumstances change.
you keep
What you're left with
We write these for your Cloud Strategy setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
document01
Application portfolio with a disposition and owner per workload
yours to keep
plan02
Landing zone reference architecture and Terraform module plan
yours to keep
design03
Identity model for people and workloads in the cloud
yours to keep
document04
Cost baseline and target-state estimate
yours to keep
plan05
Migration wave roadmap tied to contract and support dates
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your Cloud Strategy work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you score each application, and can our owners see and challenge the rules?
A disposition is only as good as the criteria behind it. With written scoring rules, an owner can argue a retire or refactor call on the facts, instead of losing to whoever is most senior in the room.
Q2
What will the plan do with applications that have no owner?
Unowned applications are where migrations stall. A plan that quietly assigns them to a wave hides a decision someone senior still has to make.
Q3
How does licensing change for each workload if we move it?
Bring-your-own-license rules differ by cloud, by managed service and by vendor contract. An estimate that ignores them can be wrong by more than the whole infrastructure line.
Q4
Which vendor support dates are setting our timeline?
Windows Server 2016 extended support ends in January 2027, and .NET 8 support ends on 10 November 2026. Plan waves without dates like these and you end up doing emergency upgrades later.
Q5
Will the landing zone design arrive as Terraform modules or as a diagram?
You can't test a diagram. Terraform modules go through your normal code review and get applied in a sandbox account before anyone commits to them.
01How long does a cloud strategy engagement take?
It depends on how many applications you have and how good your inventory is. A small portfolio with a current CMDB moves quickly. Without one, discovery takes longer, and we'd rather tell you that early than guess.
02Should we follow AWS Well-Architected, the Azure Cloud Adoption Framework or Google's Architecture Framework?
Use whichever one matches your main cloud. They overlap a lot anyway. We map our recommendations to it, so your architecture reviews and your conversations with the cloud provider use the same terms.
03Is multi-cloud a good idea?
For specific workloads, sometimes. A data platform on one cloud and Microsoft workloads on Azure is common and sensible. Running every application on two clouds usually doubles the skills you need and halves the discounts you get.
04Do you also carry out the migration?
Yes. The same team can run the waves, which keeps the reasoning behind each decision with the people doing the work.
05Do we need to clean up our CMDB before a strategy engagement?
No. We reconcile what you have against discovery tooling and billing data, then interview owners to fill the gaps. A current CMDB speeds things up, but waiting for one usually delays the plan more than it helps.
related
Often paired with
Projects on Cloud Strategy usually end up touching one of these, so they're worth a look.
