The most common failure in a Drupal modernization program is not technical. It is that the platform is delivered, the project team disperses, and nobody owns it. Six months later patching has drifted, monitoring alerts to a mailbox nobody reads, and the restore has still never been rehearsed.
Managed services is the answer to a question that should be asked before go live rather than after: who runs this, and what does running it actually involve?
What a managed platform used to absorb
Organizations leaving a proprietary Drupal platform are often surprised by how much operational work was included in the subscription and therefore invisible.
Underneath the application, somebody was patching an operating system, a PHP runtime, a database engine and a base image. Somebody was watching capacity. Somebody was taking backups, and answering when the site was slow at nine on a Monday.
None of that stops being necessary when the platform moves into your own account. It stops being included. The full list of what has to be replaced is in what actually has to be rebuilt; this article is about the row at the bottom of it, which is the one that never ends.
What the work actually consists of
Platform operations
Keeping the environment healthy: capacity, scaling behavior, certificate renewal, edge configuration, storage growth and the accumulating small changes that keep infrastructure matching its definitions. Drift is normal, because somebody will change something in a console during an incident and that is often the right call. Detecting drift on a schedule is what stops it accumulating silently.
Patching, which is the real recurring cost
The unglamorous truth of an estate is that most operational effort goes into keeping things current, across two tracks that behave differently.
- The platform underneath. Operating system, PHP, database engine, container images. Routine, relentless, and it needs an owner rather than an intention.
- The application dependency tree. Drupal core, contributed modules and PHP libraries. Composer describes itself as a tool for dependency management in PHP and is explicit that it is not a package manager in the same sense as Yum or Apt, because it manages libraries per project. Per project is what allows each site to be updated and tested independently, and it is also why an estate needs the coverage reported rather than assumed.
Security updates need a separate, faster path with a pre-agreed decision about what may bypass the normal cadence and who authorizes it. That decision should exist before it is needed, not be made in the hour an advisory lands.
The measure worth reporting is coverage: on any given day, which sites are behind and by how much. Without that number, patching is a matter of belief.
Monitoring and incident response
Watching is not the same as being watched. Monitoring produces signals; a service produces a response.
What has to exist: thresholds that page a named person, a runbook that says what to look at first, an escalation path that works at three in the morning, and a review afterwards that changes something. An alert nobody owns is a log line with ambition. What to watch is covered in Drupal observability.
Backup rehearsal
Backups run themselves. Restores do not, and a backup that has never been restored is a hypothesis.
A monthly restore of a representative site into a scratch environment, with the elapsed time and anything missing recorded, is what turns a policy into a capability. NIST supplies the two objectives that make the exercise measurable: the recovery point objective as the point in time to which data must be recovered, and the recovery time objective in terms of the maximum amount of time a resource can remain unavailable. If the rehearsal takes longer than the stated objective, the objective is aspirational. See backup and disaster recovery.
Release support
Somebody has to maintain the pipeline, keep the shared templates current, hold the approval gate, and be available when a release does not go as expected. A pipeline nobody maintains degrades quietly, and the first evidence is usually a security check that has been failing for weeks and being overridden.
Change and capacity
Requests arrive continuously: a new site, a new environment, a certificate, a scaling change, an integration. Handling them predictably is what makes the platform feel like a service rather than a queue. Where an action is safe and repeatable, it should be offered directly to delivery teams rather than through a ticket, which is self-service platform operations.
Reporting
Availability, incidents and their causes, patch coverage, capacity trend, security findings and their age, and the restore rehearsal result. This is what lets somebody outside the team form a view without asking, and it is the part most often reduced to a green dashboard that answers no question anyone had.
The models, and what each is honestly good for
Three arrangements, and the choice is usually about capacity and continuity rather than capability.
Internal. Full control, full context, and full exposure to the rota problem. It works where there is genuinely a team rather than one capable individual. The question to ask is what happens when that person is on leave during an incident.
External. Continuity, an existing rota, and accumulated experience of failure modes. The trade is context: an external team knows platforms, and needs deliberate effort to know yours.
Shared. The common arrangement in practice. The organization keeps architecture and change authority; a partner carries the rota, the routine and the out of hours. It works when the boundary is written down and fails when it is assumed.
Owning the cloud account and staffing a platform team are separable decisions, and conflating them is what makes some organizations stay on a proprietary platform longer than they need to.
What to agree before go live
These are cheap to settle in advance and expensive to negotiate during an incident.
- Hours of cover, and what happens outside them.
- Response and resolution expectations by severity, and who classifies severity.
- The patching cadence, and the separate path for security updates.
- Who may approve a production change, and who may make one during an incident.
- The recovery objectives per site, set by the business.
- The restore rehearsal schedule, and who receives the result.
- What is reported, to whom, how often.
- What is explicitly out of scope, which matters more than most of the above.
The last item prevents the commonest dispute in managed services, which is not about performance but about whether something was ever included.
Where LABUSA fits
LABUSA's technical capabilities span private infrastructure, public cloud, cybersecurity, enterprise architecture and AI implementation, which is the combination platform operations actually requires.
LABUSA operates hybrid infrastructure combining privately hosted infrastructure with AWS, AWS GovCloud (US) and Microsoft Azure services, and runs privately hosted infrastructure from a carrier-neutral data center facility in the Houston area. It uses AWS to provide disaster recovery and failover capability for designated websites and web applications hosted within that private infrastructure.
LABUSA also runs Drupal itself, including AI-assisted Drupal work, under a rule worth stating because it is the same discipline this article recommends: that work is performed within a controlled development environment, and AI-assisted content is reviewed and approved by a person before promotion to public-facing systems.
The first ninety days after go live
Managed services is usually described as a steady state, and the period that decides whether it becomes one is the three months immediately after a migration. The platform is new, the operating team is new to it, and the assumptions built during the project have not yet met a full cycle of real use.
Four things are worth treating as explicit work rather than as things that will settle.
Tune the alerting. Thresholds set during the build were guesses against synthetic load. The first month produces the real baseline, and the useful exercise is to remove alerts that fire without anyone acting on them. An alert that has been acknowledged and ignored twenty times has trained the team to ignore the next one, which will be the real one.
Meet the cycles the project never saw. A month end, a scheduled bulk import, an academic term start, a campaign. Each exercises a part of the platform that a Tuesday afternoon does not, and each is a legitimate reason to revisit capacity rather than a surprise.
Rehearse the restore early, not at the end of the first quarter. If it is going to be uncomfortable, it is better to discover that while the project team is still reachable and the decisions are still remembered.
Close the handover gaps deliberately. Every handover is incomplete. The productive habit is to record each thing the operating team had to ask about, and convert it into documentation as it arises, rather than scheduling a documentation exercise that will not happen.
Run in parallel with this, keep the previous platform available and read only until the last site has been through a full cycle. The cost of a few weeks of overlap is small compared with the cost of discovering something was never migrated after the source was decommissioned.
How to tell whether an estate is actually managed
Four questions, answerable by demonstration rather than by document.
- Which sites are behind on updates today, and by how much?
- When was the last successful restore, and who performed it?
- Who is paged at three in the morning, and what do they open first?
- What changed on the platform last month, and where is that recorded?
Question two is the one that most often produces a pause. Question four is the one that reveals whether infrastructure is still matching its definitions.
Managed services is the phase that follows delivery in Drupal cloud modernization, and naming the operating model before go live is what keeps a good platform good. If you would like to work through the four questions against your estate, that is a straightforward conversation.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.