Entrazure
What the engagement decides
Target architecture. What belongs in Azure, what stays on-premises under Azure Arc, what is retired instead of moved, and what waits because the case is not there yet. The output names platform services rather than categories, because a target architecture that says “a data platform” cannot be estimated and a target architecture that says Microsoft Fabric with a governed workspace model can.
Platform choice. Region strategy and data residency, the boundary between managed services and virtual machines, and whether identity consolidates into one Microsoft Entra ID tenant or stays federated. Each choice is recorded with its cost, its owner and its reversal cost, which is the number most strategy work leaves out.
Build or buy. The question that decides half the budget. Where a Microsoft service already does the job, configuring it well beats building an equivalent and maintaining it forever: Copilot Studio against a custom agent, Power BI against hand-built reporting, Azure Integration Services against a bespoke middleware layer. Where buying would put a core business process inside something you cannot port, we say that as well. Logic Apps is the honest example, and which side of the line a given process falls on is written down before anyone builds on it.
Sequencing. What comes first is a dependency question, not a preference. A landing zone before a migration, identity before Copilot, data governance before AI. Every phase gets an entry condition and an exit condition, so it is visible when a phase is actually finished rather than merely over budget.
The budget. A cost model separating run cost, project cost and licensing, with the assumptions on the same page as the totals. Reservations, Azure Hybrid Benefit and the licensing position are modeled explicitly, because a cloud business case that ignores them is wrong by a margin that will be noticed in the first quarterly review.
Who owns it afterward. The record belongs to your organization and is written to be read by people who were not in the room. A strategy that lives in one person’s head is a risk to you whichever side of the table that person sits on, so we do not produce one.
Why a decision record instead of a presentation
A deck is optimized for the meeting. A decision record is optimized for the eighteen months after it, which is when the questions actually arrive.
Each decision gets one page: the context, the options that were genuinely considered, what was chosen, why, what it would cost to reverse, and who agreed to it. It reads the way an engineering team already documents architecture decisions, and it lives in your repository alongside the infrastructure code, so it is versioned, reviewable in a pull request and diffed when it changes.
That format survives staff turnover on both sides. It also survives an audit, because “why is production configured like this” has a written answer with a date on it, which is a materially better position than a slide nobody can locate.
How the engagement runs
Phase 1, evidence. Read-only access to the estate, plus the contracts, the licensing position and the actual spend. Interviews with the people who operate things rather than the people who present about them. Nothing is designed in this phase, and nothing in production is touched.
Phase 2, options. Two or three credible target architectures, each costed, each with what it forecloses stated plainly. Options that we would not recommend are still written up, because a strategy with one option in it is not a strategy.
Phase 3, decisions. Working sessions where decisions are taken rather than deferred. Anything that cannot be decided becomes a recorded open question with an owner and a date, so it is visible instead of quietly missing.
Phase 4, the board version. The same content, shorter: what is being asked for, what it costs, what it buys, and what happens if nothing is approved. Written so a non-technical director can challenge it, because a budget that cannot be challenged is usually a budget that was not read.
What you keep
- The decision record, one page per decision, in your Git organization.
- A target architecture that names the services it depends on.
- A cost model separating run, project and licensing, with editable assumptions.
- A phased roadmap with an entry and exit condition and a cost per phase.
- The register of open questions, with an owner and a date against each.
- The board version, in the format your directors already read.
Who this is for
Organizations facing a forcing event: a data center lease ending, a virtualization renewal, an acquisition to absorb, an ERP replacement, an AI mandate handed down by a board, or a first serious commitment to Azure. It is also for organizations that already hold a roadmap and suspect the problem with it, which is usually that it was written by the vendor selling the largest item on it.
It works particularly well immediately before a build, because the decisions this engagement settles are exactly the ones an Azure landing zone implementation would otherwise have to improvise in week one.
Who this is not for
If the destination is already decided and funded, skip this and start building. The landing zone or the migration engagement is a better use of the money.
If what is wanted is a document that ratifies a decision already taken, we are the wrong firm. We will write what we actually think, including the part where the chosen direction is more expensive than the alternative, and paying us to agree with you is poor value.
If the estate is small and stable and nobody is asking for change, a strategy engagement is overhead. Buy an assessment instead and act on the three findings that matter.
Related
- IT modernization consulting, when the constraint is a legacy portfolio rather than a blank page.
- Azure landing zone, the first build most roadmaps sequence.
- Fractional CIO and IT leadership, when the roadmap needs someone accountable for it month to month.
- Azure assessment, the two-week entry point when the question is narrower.
- All Azure services, the catalog a roadmap can call on.
Questions we get
Is this a document or a project?
It is an engagement with a fixed scope that produces documents you own: a decision record, a target architecture, a costed roadmap and a board version of the same content. It is not a retainer, and it is not a discovery phase that quietly becomes delivery. The scope, the duration and the readout date are agreed before signature.
Who writes it?
A team of senior architects, working as a practice rather than as an individual. Every decision is recorded with its context and its reason, reviewed inside the practice before it reaches you, and stored in your repository. That is deliberate: a strategy that only makes sense to the person who wrote it is a dependency you did not ask for.
You are a Microsoft partner. Will the answer always be Azure?
Not always, and the record says where it is not. We are a Microsoft AI Cloud Partner and a direct CSP, which is written on the first page of the report rather than discovered later. Where a workload is cheaper or safer where it already runs, that is the recommendation, and Azure Arc is how it stays under one operating model.
Can you work alongside our incumbent partner?
Yes, and it is common. The strategy names what each party is good at and what should be moved. We do not require the incumbent to be replaced, and we do not take referral fees from any vendor, so the sequencing argument stands on its own.
Does the roadmap commit us to using you for delivery?
No. Every artifact is written to be executed by someone else: named services, entry and exit conditions per phase, and a cost model with visible assumptions. If we are the wrong firm for the build, the roadmap still works, and a roadmap that only we can execute would be a sales document.
What if leadership disagrees on the destination?
Then that is the first finding, and it goes in the report in plain language. Disagreement about the target is a governance problem, not an architecture problem, and no amount of design work resolves it. We can facilitate the decision and record what was agreed. We cannot decide it for you.
Have a question about this work?
Three fields. An architect reads it and answers within one business day.