Skip to main content
ProtoComet
ProtoComet

  • Azure by Decision, not by Accident.

    We start from what is actually running, then decide what moves, what stays, how it is secured and run, and the order it all happens in. A strategy your team can build against.

Where this actually breaks

Nothing here shows up as an outage. It shows up as a migration that takes twice as long, a bill nobody can explain and an audit nobody wants to run. These are the patterns we find most often in Azure estates.

Everyone agrees on Azure. Nobody agrees on what that means

“Cloud first” is a direction, not a decision. Which workloads move, which services they use, what stays and why: when nobody answers these centrally, every team answers them on its own, and differently.

The foundations were built for your first app, not your tenth

Identity, networking, environments and access were set up quickly for a pilot. That pilot now carries production, customers and a larger team, on a setup nobody designed for that weight and nobody wants to touch.

Every new project starts from a blank page

Compute, database, logging, networking: chosen fresh each time by whoever is building. Six applications built six different ways, nothing reviewed against a standard, and every handover starts with a tour.

Your architecture lives in one person’s head

The diagram in the deck shows a tidy design. The portal shows something else. The only person who knows why things are the way they are is busy, or has left, so every change carries more risk than it should.

Baseline to blueprint: six steps to a designed estate

The order matters. Direction before design, design before patterns, patterns before the roadmap. Each step produces a written artifact the next step is checked against.

1. Baseline

he estate as it runs: subscriptions, networks, identities, resources, pipelines and spend, read from the portal and the code. The gaps between this and the official diagram are the first findings.

Output: Estate baseline

2. Direction & constraints

What the business needs Azure to do in the next three years, and what limits the answer: data residency, regulation, systems that stay on-premises, partner connections, budget and the skills the team has.

Output: Direction & Constraint register

3. Platform Foundations

The landing zone: how subscriptions, networks, identity, security and shared services are organized. Designed once, so every workload after it starts from a decided place instead of a blank page.

Output: Landing zone design

4. Workload Patterns

A set of approved shapes: a web application, an API, a batch job, a data store. Each with its compute tier, data service, observability and network placement decided, so that "which service?" is answered before it is asked.

Output: Pattern catalogue

5.Decision Records

Every significant choice written with the alternatives considered, why they lost, and the condition that would reopen the decision. This is what makes the estate reviewable by anyone, later.

Output: Architecture register

3. Roadmap

How the estate gets from baseline to target: what moves first, what is retired, what stays with a date to revisit, and who owns the platform once it is running. Costed as ranges.

Output: Target-state roadmap

How the work actually runs

Fixed price, because an architecture for a known estate is a known quantity. The scope is the baseline, the design and the register; the build is usually done by your platform team or your partner, to the specification, with ProtoComet reviewing. Where there is no one to build it, we can build it for you.

Design in weeks


Typically four to six weeks for an existing estate, shorter for a greenfield one. Read access to the subscriptions and the deployment repositories from day one. Two working sessions with the engineers who will build it and one with whoever signs off the network and identity decisions.

Review, if you already have a design


A shorter fixed-price engagement: the baseline, a review memo against the six steps, and a prioritized list of what to change. If the existing design is sound, the memo says so and the engagement ends there. If not, you know exactly what to fix first, and why.

What senior-only means here


The person who reads your network peerings writes the landing zone design and stays through the build, whether your team, your partner or ProtoComet does it. If a decision in the register turns out to be wrong in production, its author is still on the account to change it and write down why.


What you walk away with

A strategy and design your team, any partner, or ProtoComet can build from, and the reasoning that lets anyone review it later.

➖ Cloud strategy on one page. Which workloads move, which services they use, what stays, and what the estate looks like in three years, in words the board can act on.


➖ Direction & constraint register. What the business needs from Azure, what the design had to fit inside, and why. The first thing a reviewer reads.


➖ Architecture register. Every significant decision with its alternatives, reasoning and the condition that would reopen it.

➖ Platform design. The landing zone and a small set of approved workload patterns, written as a buildable specification, so every new workload starts from a standard instead of a blank page.


➖ Estate baseline. What is actually running, with the gaps between it and the official diagram named and prioritized.


➖ Quarterly one-pager. What the estate costs, what changed, what is at risk, what is recommended, for your board or just for your own records.

Our Way

Most Azure strategies and architectures are written from the reference diagrams outward. Start with the enterprise-scale landing zone, remove what does not apply, add the customer’s logo. The result is usually correct and usually far larger than the estate needs, because the reference was drawn for an organization with a platform team of twelve.


This practice works from the baseline inward. What the business needs, what is running, what it depends on, and what the team can actually operate at two in the morning. The design is the smallest structure that meets those needs, and the register records where it deliberately falls short of the reference and why.


20 years inside Microsoft estates taught me that the architecture that gets followed is the one the team understands. A strategy nobody can explain is a slide, not a strategy.

The right size for a landing zone is the smallest one that will still be right in three years. The reference architecture is where you check your work, not where you start it.


Yogesh, founder and principal consultant

Questions clients typically ask

Usually the opposite. The design is sized to your estate, not to the reference architecture, so a small company gets a small design: often two subscriptions, one network and a handful of patterns. Getting it right at five workloads costs far less than untangling it at fifty.

Not by default, but yes if you need it. The design is written as a buildable specification, and most clients have their platform team or partner build it, with ProtoComet reviewing the pull requests and pairing on the first instance of anything new. If you have no one to build it, or would rather the author did, ProtoComet builds the foundations as a separately scoped phase, as code your team owns from day one.

Usually, and the fixed-price review is the way to find out. Most existing estates were built well and documented badly, so the useful output is the register: the decisions that were made, written down so they can be reviewed. Where the design itself has problems, the review memo says which ones matter and which can be left.

An accelerator is a good way to build a landing zone quickly once the decisions are made. It is not a way to make them. The subscription model, the network topology and the identity model are decisions about your organization, and an accelerator has defaults for all of them that may or may not fit. Have the design done, then let your partner accelerate the build of it. That is the arrangement this practice recommends and works in.

Application Modernization service designs the target architecture for one legacy .NET estate that is about to be modernized. This engagement designs the strategy and platform for your whole Azure estate, whatever is being migrated. If you are modernizing and have no landing zone yet, this usually comes first.

Ready to move?

Let's talk about where you are and where you want to go.  and whether modernization is even the right answer this year. If it is not, you will hear that.

Let’s Talk