A managed server or separate cloud services?
Maintenance problems, higher traffic peaks and corporate IT requirements lead to different target architectures. Sometimes a managed server is enough. In other cases, separate services for the application, database and files make sense. Kubernetes is one possible operating platform, not a prerequisite for TYPO3.
Before choosing a setup, we inventory the core and PHP versions, extensions, Composer dependencies, file storage, database and external connections. We also include easily overlooked tasks: scheduled imports, PDF generation, search indexes, image processing and outgoing email.
Code is replaceable. Editorial data is not.
A new release can be built from the repository. Uploaded images and the current database must not disappear when the application is replaced. Code, configuration, credentials and changing data therefore need separate treatment.
When several application instances run in parallel, they need access to the same authoritative content and files. An upload stored only in one container could disappear when it is replaced or be unavailable from another instance. Shared storage or an appropriate storage integration is an architectural decision.
Check scheduled jobs, search, uploads and email
We check these functions in the new environment using existing data and the intended user roles:
- Scheduled and background tasks
- What runs when, and which process runs it? With multiple instances, an import must not accidentally start twice.
- Search, caches and sessions
- Search indexes need to be built. Cache configuration and authenticated users must still work when requests are distributed across instances.
- Files, images and documents
- Uploads, permissions, image processing and custom PDF features are checked with real examples, not just an empty test installation.
- Integrations and email
- Outbound connections, IP allowlists, certificates and mail delivery may change. A submitted form is only fully checked when its message arrives at the intended destination.
Rehearse the switch first
A trial migration shows how long data transfer and follow-up work actually take. For the production switch, we establish when editing pauses, which data is synchronised last and how DNS, certificates and redirects change.
The CI/CD pipeline builds and tests a versioned release. Once that build has passed staging checks and been approved, it moves to production unchanged. For container-based hosting, that means deploying the tested container image rather than rebuilding it for production. Database migrations need separate handling: rolling back the application does not undo changes to the data or schema. We check whether the previous code can work with the changed database and rehearse the rollback procedure before deployment.
Monitoring, updates and recovery
Who responds to an alert? Who updates PHP and extensions? How are backups protected and restores rehearsed? Responsibilities need to be agreed between the business, developers and hosting partner.
Acceptance checks also cover redirects, search-engine access, response times and essential user journeys. We compare them with the starting point. Only then can we judge whether the move achieved its purpose, rather than merely changing the server’s address.
Uploads must survive instance replacement, scheduled jobs must not run twice, and rollback must account for both code and database changes. These dependencies shape the migration.