Here is a way a technically successful migration is judged a failure.
The new platform is better in every measurable respect: cheaper per site, properly monitored, backed up, patched, with security gates in the pipeline. And a developer who used to create a test environment by clicking a button now raises a ticket and waits two days. Within a quarter, the consensus is that the old platform was better.
That consensus is not unreasonable. Self-service was a real capability, and replacing it with a queue is a regression that the architecture diagram does not show.
What self-service actually means
Not giving developers cloud console access. That solves the waiting and creates a considerably larger problem.
Self-service means a defined set of approved actions, each implemented once as automation, exposed to people who are authorized to invoke them, without those people holding the underlying permissions. The automation holds the permissions. The person holds the right to ask for the action.
That distinction is the whole design. It is what lets a developer create an environment without being able to create arbitrary infrastructure, and it is why the catalog is a security control as much as a convenience.
The actions worth exposing
Ordered roughly by how often they are wanted.
- Create an environment for a branch or a piece of work, from the standard definitions.
- Refresh an environment from production, with data sanitized on the way.
- Deploy a release to a non-production environment.
- Show status: what is deployed where, when, and by whom.
- Clear or warm a cache without a person deciding which caches.
- Run a backup on demand before something risky.
- Restore to a scratch environment, which is also how restore capability gets rehearsed by accident, in a good way.
- Enter or leave maintenance mode.
- Destroy an environment, which matters more than it sounds.
- Provision a new site, usually the highest value and the most governed.
Two of those deserve comment. Refresh from production is the most frequently requested action on most estates and the one with legal consequences, because it copies personal data into an environment with looser access. Sanitization belongs inside the action rather than as a step somebody remembers.
Destroy is the action most often omitted, and its absence is why cloud costs grow. If nothing tears environments down, nothing tears environments down.
Where the boundary sits
Three tiers, and putting an action in the wrong tier is the usual design error.
Self-service, no approval. Actions confined to non-production, reversible, and bounded in cost. Creating a development environment. Clearing a cache. Refreshing staging.
Self-service with approval. Actions that touch production or spend meaningfully. Production deployment. Provisioning a new site. Restoring over an existing environment. Microsoft describes control over whether a stage should run as being exercised through approvals and checks, which is the mechanism that makes this tier practical rather than theoretical.
Not self-service. Changes to shared foundations: networking, identity, the edge, the pipeline templates themselves. These go through engineering review, because their blast radius is the estate.
The failure is to put everything in the third tier because it is safest. That reproduces the ticket queue and loses the capability the platform is supposed to provide.
Quotas, expiry and cost
Self-service without limits becomes a cost problem within a quarter. Three controls handle it, and all three should be in the automation rather than in a policy document.
- Quotas. A team may hold a certain number of environments. Wanting another means retiring one, which is a conversation the automation can have.
- Expiry. Environments created by self-service expire by default, with a warning and a means to extend. Nothing else reliably reclaims them.
- Attribution. Every resource is tagged with its owner and purpose at creation, because retrofitting attribution across an untagged estate is a project nobody funds.
Expiry is the one that meets resistance and the one that matters most. An environment that has to be renewed is an environment somebody is still using.
How to build it, in order
The mistake is starting with the portal. The portal is the last thing.
- Automate the action so it runs reliably, idempotently, and reports what it did. This is Drupal lifecycle automation, and it is the actual work.
- Give it an interface a machine can call, so it can be invoked from more than one place.
- Put authorization in front of it, tied to the organization's existing directory rather than to a second list of people.
- Expose it through whatever surface suits: a pipeline anyone can run, a chat command, a catalog, a portal.
Steps one to three are the platform. Step four is presentation, and it can be changed later cheaply. Organizations that begin at step four produce a portal whose buttons open tickets, which is theater.
Backstage is one possible technology for step four and is not required. A pipeline in the delivery tool that any authorized person can run, with parameters, covers most of this list on day one and costs almost nothing.
The audit trail is a feature
An underrated consequence: because every action runs through automation, every action is recorded. Who asked, what ran, when, against which environment, and what the result was.
That is considerably better evidence than the arrangement it replaces, where a privileged engineer performed the action directly and the record is a memory. Microsoft notes that deployment history of an environment can be used to identify the source of changes, and the same property applies to any action modeled this way.
It also removes a class of standing privilege. If routine work is done by automation, ordinary engineers do not need permanent access to production, which is a genuine security improvement rather than a compliance gesture. That connects directly to Drupal cloud security architecture.
Provisioning a new site, which is the hard one
Every other action operates on something that exists. Site provisioning creates it, and that makes it the action with the most steps, the most approvals and the most ways to be left half done.
A complete provisioning action has to arrange all of the following, and stop cleanly if any of it fails:
- A repository from a template, with branch policies and the shared pipeline already attached.
- The infrastructure for each environment, from the reusable per site module.
- A database, storage, and the credentials for both, placed in the secret store rather than emailed.
- Hostnames and certificates, including the non-production ones.
- Edge configuration, with the caching rules the site's class implies.
- Backup schedule and retention appropriate to the site's recovery objectives.
- Monitoring: dashboards, alerts and their routing to the owning team.
- An initial Drupal install, with the organization's baseline configuration and modules.
- A record of who owns this site, which is the field that will be needed in two years.
Steps six, seven and nine are the ones most often left out of a first implementation, and each has a predictable consequence. A site provisioned without a backup schedule is discovered during an incident. A site provisioned without monitoring is invisible until somebody complains. A site provisioned without a recorded owner becomes part of the long tail that the next migration will have to investigate.
The discipline that avoids all three is to treat provisioning as the action that must produce a complete site rather than a running one. If observability and backup are provisioned by the same automation that provisions the environment, coverage is complete by construction rather than by diligence. That is the argument in Drupal observability and in backup and disaster recovery, and it is the reason provisioning belongs in the approval tier rather than the open one.
What to measure
Whether it is working is measurable, and the numbers are easy to collect.
- Time from request to environment. The number that should have improved. If it is worse than the old platform, the catalog is not covering what people actually ask for.
- Proportion of requests self-served. If most work still arrives as tickets, the catalog is missing the common cases.
- Environments in existence, and their age. A rising count with a rising median age means expiry is not working.
- Failed self-service actions. Each one sends somebody back to a ticket, and teaches them not to try again.
The last is the one to watch early. A catalog that fails one time in five is worse than no catalog, because it costs the attempt and the ticket.
A reasonable first version
Three actions cover most of the demand on most estates: create a development environment, refresh staging from production with sanitization, and show what is deployed where. Ship those, in the tool you already have, before building anything that looks like a product.
Self-service is one row of what actually has to be rebuilt when a managed platform is replaced, and it is the row whose absence is felt daily by the people whose opinion of the platform matters most. It sits inside Drupal platform engineering and modernization, and if developer experience on a new platform is being described as worse than the old one, this is usually the reason.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.