24/7 patches and weekday major upgrades — standardised, documented, reproducible

There are many agencies. But who delivers 24/7 security patches and major upgrades on weekdays at industrial quality? We show how our model works.
There are agencies as far as the eye can see. But the decisive question you should be asking yourself as IT lead or managing director in the mid-market isn't who can build a website. It is: who keeps your systems secure, current, and economical for years — in such a way that your operations don't suffer from nightly fire-fighting?
At Moselwal we have a clear answer to that. We deliver 24/7 security patches and weekday major upgrades — standardised, documented, and reproducible. That sounds sober, and that's exactly how it should be. Because operations shouldn't be exciting.
Why 24/7 patches have to be the standard
Security holes don't keep office hours. When a critical TYPO3 core vulnerability, a CVE in a PHP library, or a problem in a system package is published, every hour counts. Anyone who only talks about it in Monday's stand-up has offered an attack surface over the weekend.
That's why patches at our place run automated. Security updates are built, tested, and deployed to staging by our CI/CD pipeline. If the patch is low-risk and the test set is green, it goes into production on weekdays even outside business hours. You get a notification, not an email chain at three in the morning. For critical CVEs, a clearly defined emergency process exists with on-call duty — and a rollback path we've already rehearsed once before.
Major upgrades belong on weekdays — no hero stories
A TYPO3 LTS upgrade isn't a weekend project. We believe every release change should happen on a weekday, when the team is reachable and your business side can immediately clarify any questions. What used to cost a weekend and rattle nerves is today a planned slot in a defined time window for us.
Our 3-layer model makes that possible: a standardised infrastructure, a uniform TYPO3 base, and a clean separation of customer-specific extensions. Anyone working on this base has no surprises. An upgrade from TYPO3 12 LTS to TYPO3 13 LTS runs with us as a reproducible procedure: check Composer dependencies, make extensions compatible with the new API, run automated migrations, check reference pages in visual regression tests — and only then does it go to production.
Rollback is not plan B — it's part of the plan
We assume something can go wrong. So before every major upgrade, a rollback plan is ready, including a database snapshot, release tag, and documented procedure. You don't have to ask "what if…?" — the answer is already on the table.
What this concretely brings you
Industrial quality in maintenance and upgrades means for you:
- Predictable costs. No flat rates for emergencies, but fixed maintenance windows and calculable LTS paths over several years.
- No silent risks. No backend system running for two years on an unpatched PHP version because nobody dares touch it.
- Documentation that's real. Every change creates an entry in the change log, every architecture decision is recorded in an ADR, every upgrade is accompanied by a runbook. If your internal colleague wants to understand in two years why an extension was built one way and not another, they'll find the answer.
- Reproducibility. The same process runs on project A as on project B. That means we get faster, you pay less for learning.
Why standardised is more economical
Many customers come to us with the assumption that standardisation means restriction. The opposite is true. Because we're highly standardised in maintenance and upgrades, we have time to work individually in the places that are really relevant for your business: your editorial processes, your interfaces, your landing-page templates for campaigns.
Our offering CMS as a Service and DevSecOps as a Service combines exactly that: an industrialised foundation and room for your specifics. You don't save in the wrong places — you save in the places where every other agency would also build the same thing and just reinvent the wheel.
And if you're set up differently today?
That's the normal case. Most existing customers who switch to us have setups grown over years, fragmented maintenance contracts, and at least one extension nobody dares touch any more. We take over such systems regularly. The first step is always the same: an honest look at the current state, a clear plan, and a first small step towards reproducible operations.
![[Translate to English:] Abgedunkelter Leitstand bei Nacht mit zwei leeren Bürostühlen vor einer Wand aus leuchtenden Monitoren.](/fileadmin/_processed_/f/d/csm_b7b08496fe8ccb3bb2222fd5e34ce67fefb4d246fc79b551aa7016496acb085d_1b1923023e.jpg)
Let's talk
If you have the impression that maintenance and upgrades cost too much energy in your organisation, let's talk for 30 minutes. No pitch, no slides, just questions and answers — and at the end you'll know whether our model fits you.
Frequently asked questions
What customers most often ask us about this topic — answered openly.
How do you ensure individual extensions don't break?+
For every individual extension there is a defined compatibility path per TYPO3 major release. We maintain an automated compatibility check against the next LTS long before the upgrade is due. Surprises on upgrade day belong to the past.
Do you also take on legacy systems that weren't built by you?+
Yes, that's the common case. We start with a due diligence step — security, maintenance and architecture review — and show you what stays, what has to be modernised, and what economically can no longer be saved. After that we bring the environment into our standard operation.
How does this fit with our own release windows?+
We coordinate upgrade dates with your departments and campaign planning. Maintenance and upgrades never run across active campaigns, seasonal peaks or product launches. You retain planning certainty within your own cycles.
Do we have to release special budget for major upgrades?+
No. LTS upgrades are included in our service contract and follow a predictable cycle. You get advance notice, a proposed date, and a clear list of changes. No surprise invoices, no discount games around end-of-life dates.
What happens if a patch causes problems in production?+
For every patch a rollback path is ready that we have tested up front. If a problem appears after deployment, the environment falls back to the last stable state at the press of a button. We investigate the cause, adjust the patch or test coverage, and try again in a controlled way — no all-nighters.