Azure Deployment Environments and Microsoft Dev Box are both in maintenance mode. Most of the "build an internal developer platform on Azure" writing currently in circulation nominates one or both as the foundation. That advice has not caught up.

Microsoft's wording for Azure Deployment Environments is short enough to quote in full: "Azure Deployment Environments is in maintenance mode, with no additional features planned. Existing capabilities remain available."

For Dev Box it is more pointed: "Dev Box is now in maintenance mode, with no additional features planned", and "Customers should consider Windows 365 as the recommended path forward."

Several announced Dev Box features were cancelled before they shipped, including on-behalf-of creation, firewall service tags, developer offboarding, single sign-on for existing machines, auto-remediation and the latency improvements. There is no migration guide yet. The documentation says guidance will be provided.

Maintenance mode is not end of life, and nothing you are running today stops working. But it changes the calculation. A service with no further features is a service you should not be building a five-year platform strategy on top of, and it is a service whose gaps will stay gaps.

What has not gone into maintenance

The awkward part is that the two services now parked are the ones that felt most like a platform, in the sense of a thing a developer touches. What is left is less exciting and considerably more durable, because it is the substrate rather than the surface.

Landing zones and subscription vending. This is the genuinely platform-shaped primitive in Azure: a request produces a subscription placed in the right management group, with networking, RBAC and identity already wired. It is the paved road, expressed as infrastructure rather than as a portal.

Read Microsoft's own framing carefully, because it cuts against the way golden paths are usually described. It is not "pick one blessed route and make everyone take it". Microsoft says that organisations "that only provide a 'one size fits all' approach to subscription vending often limit their internal customers' flexibility" and that "platform teams need to provide various product lines to cater to their organization's needs", noting that customers typically start with three: sandbox, corp connected, and online.

A small catalogue of paved roads, not one. That is a more useful model than the singular golden path, and it is the difference between a platform people route around and one they use.

Azure Verified Modules as the module layer. Read the support statement before you depend on it. The commitment is a meaningful response toward resolution within five business days, and Microsoft is explicit that this is "not for a fix within these durations". Modules also carry lifecycle states, including "orphaned" for when maintainers stop responding. That is fine, and it is a great deal better than writing your own modules from scratch. It is not the same as a supported product, and the difference matters when you are telling your organisation that this is the supported way to build.

Azure Policy as the governance layer. Microsoft's framing here is the useful bit: start right and stay right, meaning catalogued templates get you compliant at creation and policy keeps you compliant afterwards. Note the warning that comes attached, because it is the thing that will bite you: while policies "can enforce compliance, they can also break applications unexpectedly". Roll them out in rings, the same way you would roll out anything else that can take production down.

On portals, Microsoft's advice runs against the instinct

Worth quoting because it is the opposite of where most platform projects start. A developer portal, Microsoft says, is "a destination rather than a starting point". Before building somewhere new for people to go, extend the surfaces they already use: the IDE, the CLI, the DevOps tooling, chat.

That ordering is well supported by evidence from outside Microsoft. Spotify, who built the most popular developer portal there is, put average Backstage adoption inside adopting organisations at around 10%. Building a second front door and then asking people to learn it is a hard way to earn attention you could have had for free.

One caveat if you standardise on azd templates

Azure Developer CLI templates are a genuinely good accelerator, and Microsoft states plainly that the templates, "including those provided from Microsoft, are not supported by any Microsoft support program or service". They are provided as is.

That is fine for a starting point and a problem for a paved road. The moment you tell your organisation "this is the supported way to deploy", you have quietly assumed the support obligation yourself. Decide that deliberately rather than discovering it during an incident.

What I would take from this

The services that went into maintenance are the ones that looked like a product. The ones still standing are the ones that look like plumbing. That is not a coincidence, and there is a lesson in it about which layer is worth building your platform on.

More generally, it is a small live demonstration of a bigger point: an internal platform is a bet on a gap, and the gap moves. Sometimes it moves because the hyperscalers close it. Sometimes, as here, it moves because the hyperscaler you built on quietly stops developing the thing you built on. Either way, the assumption is worth re-pricing on a schedule rather than at the point where someone sends you a documentation link.

That is GOV.UK PaaS in July 2022, on the day the Government Digital Service announced it was shutting it down.

By every operational measure in the platform engineering canon, it worked. It was decommissioned anyway, and the reasons GDS gave are the most useful thing published on this subject.

Here is the line the rest of this hangs on: a platform is not an asset you build, it is a bet that a particular gap is worth closing, and the gap closes without telling you.

A word on where this comes from, because it should change how you read it. I run workplace technology for 25,000 people, which is enterprise IT rather than product engineering. I have never stood up a Backstage instance. What follows is not a war story. It is what the published evidence says when you go and read it, and the evidence turns out to be stranger than the advice built on top of it.

What actually closed GOV.UK PaaS

GDS gave three reasons. Growth had stalled. The large cloud providers had, in their words, "upped their game and reduced the barriers to entry". And departments had built their own cloud engineering capability and were clustering around a Kubernetes based architecture on their own.

The tempting move is to pick whichever of those supports the argument you already hold. Read the first on its own and this is a straightforward adoption failure. Read the second and third on their own and it is pure market movement, nobody's fault.

They are the same event seen from two ends.

Growth stalls because the gap is closing. A team that can now stand up its own thing in an afternoon does not join your platform, and the number that surfaces on your dashboard is flat adoption. So adoption is the symptom you can see, and scarcity is the disease underneath it. That distinction is not academic, because it changes what you monitor. Adoption tells you how you did last quarter. Scarcity tells you how long you have got.

Every internal platform is an arbitrage on the difference between what your organisation can do on its own and what the market makes easy. That difference is the whole value of the thing. It narrows every year, and nobody sends you a note when it does.

One detail worth sitting with. The UK government's roadmap for modern digital government commits to a fresh generation of shared platforms, including a new one called internal.gov.uk "for people who work in the public sector to connect via instant messaging functionality, forums and a secure code repository", due June 2026. It makes no reference to GOV.UK PaaS, and gives no account of why the last one was retired.

The organisation that wrote the best post-mortem in this field did not cite it in its own next plan.

The literature was not written for you

If you run an enterprise IT estate rather than a product engineering organisation, this is the part that matters.

Look at who the examples are. Team Topologies publishes thirteen platform team industry examples. Exactly one is public sector. The rest are Docker, Flo Health, Trade Me, Improbable, PureGym, Footasylum, Uswitch and similar. Every prescription in the field, golden paths, thinnest viable platform, stream-aligned teams, cognitive load, assumes a population of product engineers shipping services they own.

That is not most enterprise IT. If your estate is Microsoft 365, a service management tool, a fleet of endpoints, a dozen line-of-business applications and a handful of integrations, your users are not stream-aligned product teams. Your cognitive load problem is not deployment pipelines. And your adoption problem is not that developers prefer their own tooling, it is that a department will buy a SaaS product on a corporate card rather than wait for you.

The strange part is that the canonical definition already covers you. CNCF's platforms white paper says platform users "include but aren't limited to app developers and operators, data scientists, COTS software operators, and information workers". Information workers are in the founding definition. Almost nothing built on top of that definition acknowledges they exist.

The one author writing directly for this audience is Gregor Hohpe, whose 2024 book Platform Strategy has a substantial in-house IT section, including one titled "IT Platform and IT Services Are Antonyms". His failure mode for enterprise platforms will be familiar: outdated by the time they launch, restricting rather than enabling, and mandated in a last-ditch attempt to make the economics work. His evidence base is a decade of practitioner experience rather than measurement, and he names no organisations.

And the evidence under the advice is thin

Worth knowing before you cite any of it at your own leadership.

Start with the number everyone repeats, some version of "70% of platform initiatives fail". The New Stack repeats it and, to its credit, links its sources, which is how you can check them. Follow the first link and the "up to 70%" traces to a webinar registration page titled "Platform leadership 101: Why 67% of platform initiatives are failing", whose entire stated methodology is a single sentence: "Both our community surveys and broader market studies reveal that 67% of platform leaders are missing the mark on building successful, scalable Internal Developer Platforms." Follow the second, for the claim that half of platform teams are disbanded within eighteen months, and you reach a Gartner topic page that does not contain that claim at all. Its only statistic is a forecast that 80% of large software engineering organisations will have platform teams by 2026.

So the citation is not thin. It is broken.

The academic position is documented, and it is worse. A multivocal literature review published in Frontiers in Computer Science in May 2026 searched five databases and found "fewer than a dozen peer-reviewed papers from reputable venues that address platform engineering directly". No tier-A source proposes or validates a maturity model, so every maturity model in circulation comes from grey literature. And on scorecards, the main governance mechanism inside most developer portals, it found "no peer-reviewed empirical evidence of effectiveness exists despite widespread commercial adoption".

Be fair to the method here: a multivocal review deliberately includes grey literature, so a low proportion of academic sources is partly the point of the technique. The absolute count is the number that bites. Fewer than a dozen papers, for a discipline with a conference circuit and a tooling market.

The canonical artefacts have not aged well either. The CNCF Platform Engineering Maturity Model was released in November 2023 and is still v1.0. The working group that owned it no longer exists: when CNCF restructured its technical groups in May 2025, the assessment work was recorded in CNCF's own tracker as "having paused in recent months due to recent TOC changes", with the authors asking that the TOC "provide guidance as to the correct place within the community to conduct this ongoing work". A pilot assessment tool has since appeared outside the CNCF repositories, still asking for feedback.

None of that means platform engineering is wrong. It means the confident numbers in your inbox are not measurements, and you should discount accordingly, including the ones in this piece.

What is actually measured, including the uncomfortable part

DORA's 2024 report, nearly 3,000 respondents, is the strongest measured evidence in the field. Internal developer platform users showed 8% higher individual productivity and 10% higher team performance.

Throughput also decreased by 8%, and change stability decreased by 14%.

That is the field's flagship research reporting that platforms made delivery slower and less stable. DORA's own hypotheses are that a platform can add handoffs between systems and teams, or that it lets teams ship faster and therefore break more, or that instability signals teams were never properly onboarded. The report links that instability to increased developer burnout, and cautions against deploying platform engineering as a burnout remedy.

DORA's 2025 report, nearly 5,000 technology professionals, adds the finding that matters most right now: when platform quality is high, the effect of AI adoption on organisational performance is "strong and positive", and when platform quality is low that effect is "negligible". If you are being asked to demonstrate returns on AI, the platform is not a competing priority. It is the precondition. That is the strongest argument for doing this work I have found anywhere, and note that it is conditional on quality rather than on existence.

One discrepancy worth carrying. DORA 2025 reports 90% of organisations have adopted at least one platform and 76% have dedicated platform teams. A CNCF and SlashData survey of more than 400 developers in March 2026 found only 28% have a dedicated platform engineering team. Those two are not describing the same thing. When someone quotes an adoption figure at you, ask what they counted.

Nobody uses these things

Spotify, the company that created Backstage, has publicly estimated the average Backstage adoption rate at 10% inside the organisations that install it. Nine in ten of the people it was built for carry on as before.

The vendor surveys agree, which is notable given who pays for them. State of Platform Engineering Volume 4, published by Weave Intelligence with 518 respondents, found that "nearly 30 percent of platform teams still report that they do not measure success at all", and that adoption "is still frequently driven by extrinsic push or mandate (36.6%) rather than the intrinsic value necessary for true user pull (28.2%)".

Which returns you to where the idea started. When Evan Bottcher defined the digital platform in 2018, one word was doing real work: "a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product". Compelling, not mandated. A platform that needs a mandate has already failed its own definition. Even Microsoft's guidance, which has every commercial reason to encourage you, says it plainly: "Customers should want to use your platform, but not be mandated to use it."

That advice is correct, and in a regulated enterprise it is unusable as written. Which brings me to the part the literature does not cover.

Three things I would do differently

Mandate the control, never the path. In a bank, an insurer, a hospital or a government department, "don't mandate it" is not available to you, because an unpaved road is an audit finding. So mandate the outcome instead: encryption, identity, logging, network placement, data residency. Leave the route optional. This costs you nothing you actually needed, and it buys you the only honest adoption metric there is, because now the percentage of compliant workloads that came through your paved road tells you how many teams chose you when a legal alternative existed. Compare that with measuring how many workloads are compliant, which measures your auditors rather than your platform.

Your service catalogue is the portal you already have. Microsoft's own advice is that a developer portal is "a destination rather than a starting point", and that you should extend the surfaces people already use before you build a new one. In enterprise IT that surface is the service management tool, because it is where people already go when they want something. Self-service in this world usually means a request with an approval attached, not a git push, and there is no shame in that. Building a second front door and then asking the organisation to learn it is how you arrive at 10%.

Put the expiry review in the diary, and decide now who raises it. Every six months, write down what your platform makes easy, then price what it would cost a team to do that today without you, using whatever the hyperscalers shipped last quarter. If the answer is "about the same", you are running GOV.UK PaaS in 2022. The second half of that sentence is the hard one. Nobody retires a platform without embarrassment, because the person best placed to notice the gap has closed is the person whose job closes with it. GDS could do it because GDS had plenty of other work. A platform team inside a bank has no such luxury, and that, rather than sunk cost, is the real reason platforms outlive their scarcity. Name the person who is expected to raise it while naming them is still cheap.

Underneath all three sits the question nobody writes about: who funds this. In a product organisation the platform team is paid for out of engineering and nobody asks again. In enterprise IT it is funded by whoever will sign for it, and an unmandated central platform re-justifies its budget every year against projects with a named business sponsor, and loses. The person who signs is also the person who will be asked at the next audit why the controls are not uniform. Which is the first recommendation again, arriving from the other direction.

The two things that are both true

The discipline's own flagship research says platforms reduced throughput and stability. Its most-quoted failure statistic traces to a webinar title and a Gartner page that does not contain it. The company that built the most popular portal puts adoption at one in ten.

And the platform is still the thing that determines whether your AI spending returns anything at all.

You hold those together by changing what a platform is for. Not an asset you build and then defend, but a bet on a gap, priced at the start, repriced on a schedule, and closed without embarrassment when the market closes it for you. GOV.UK PaaS was not a failure. It was a correct decision at the beginning and a correct decision at the end, and the only mistake available was keeping it because shutting it down would have looked like one.

Start by writing down which gap you are betting on. If you cannot name it in a sentence, you do not have a platform, you have a project.

If you are building on Azure, two of the services most commonly recommended as the foundation went into maintenance mode this year. That is a separate post: Azure Deployment Environments and Dev Box are in maintenance mode.

Recently I stumbled upon the NetArchTest package by Ben Morris.

What is NetArchTest?

NetArchTest is a .NET library that allows you to create tests that enforce conventions for class design, naming, and dependency in .NET code bases. It is inspired by the ArchUnit library for Java. It uses a fluid API that allows you to string together readable rules that can be used in test assertions. You can use it with any unit test framework and incorporate it into your build pipeline.

It is available as a NuGet package.

How to use NetArchTest?

The basic steps to use NetArchTest are:

1. Select a set of types from a path, assembly, or namespace using the static Types class.
2. Filter the types using one or more predicates, such as ResideInNamespace, HaveDependencyOn, ImplementInterface, etc. You can chain the predicates using And or Or conjunctions.
3. Apply one or more conditions using the Should or ShouldNot methods, such as BeSealed, BeAbstract, HaveNameStartingWith, etc.
4. Obtain a result from the rule by using an executor, such as GetTypes to return the types that match the rule or GetResult to determine whether the rule has been met. The result will also return a list of types that failed to meet the conditions.

Here are some examples of rules that you can create with NetArchTest:

Classes in the presentation layer should not directly reference repositories:

var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("MyProject.Presentation")
    .ShouldNot()
    .HaveDependencyOn("MyProject.Data")
    .GetResult()
    .IsSuccessful;

Classes in the data layer should implement IRepository:

var result = Types.InCurrentDomain()
    .That()
    .ResideInNamespace("MyProject.Data")
    .Should()
    .ImplementInterface(typeof(IRepository))
    .GetResult()
    .IsSuccessful;

All the service classes should be sealed:

var result = Types.InCurrentDomain()
    .That()
    .ImplementInterface(typeof(IService))
    .Should()
    .BeSealed()
    .GetResult()
    .IsSuccessful;

Want to read more on its origin?

Ben's written a nice blog post about how he came to write this package. Especially if you're interested in what motivates people, and the path they've walked, take a look at his blog post.

Why use NetArchTest?

NetArchTest can help you to:

• Maintain the consistency and quality of your code base over time.
• Avoid the need for manual code reviews or static analysis tools that may not capture your specific architectural requirements.
• Create a self-testing architecture that can be verified by automated tests.
• Communicate and document your architectural design and conventions through code.

Conclusion

NetArchTest is a powerful and easy-to-use library that can help you to test your architecture in .NET. It can help you to enforce the rules and conventions that you have chosen for your code base and avoid the common pitfalls of architectural decay. You can use it with any unit test framework and integrate it into your build pipeline. If you are interested in learning more about NetArchTest, you can check out its GitHub repository or its NuGet page. Happy testing!