Changing Agency: Handing Over a TYPO3 Project Cleanly

Why people change

The reasons look alike. Response times that no longer fit the business. An agency that shifted focus and now handles TYPO3 on the side. Staff changes after which nobody knows the project any more. Or simply the end of a collaboration that worked for years and that both sides have outgrown.

What is almost never the reason: the system itself. A TYPO3 installation that is looked after ages slowly. What hurts in these projects is usually the care, not the technology.

What to settle before the change

Usage rights to the custom code. Templates, bespoke extensions, configuration. Without an explicit grant of rights the handover can become legally awkward, even when everything is technically available.

Where the domain sits and who administers it. Surprisingly often the registered owner on paper is the agency. That can be sorted out, but it takes time, and the middle of a handover is the worst moment for it.

Who holds the hosting contract. A customer account with the host is something different from a slot in the agency’s collective account. In the second case the change includes a move.

Which licences are running. Paid extensions, an extended support contract, services for search or forms. Every licence has a contracting party, and that party still has to be correct after the change.

The state of the documentation. Not for its own sake, but as a time factor: what is written down does not have to be reconstructed.

What a complete handover contains

A handover is complete when the new team can work without asking the old one. In practice: access to the repository with its full history, a current database dump, the file tree including uploaded media, credentials for hosting, domain and services, plus the list of installed extensions with their sources.

Then there is what never comes along automatically: knowledge about special cases. Why one page is configured differently from the rest, which import runs at night, what a particular switch in the TypoScript is for. Half an hour of conversation between the old and the new agency is worth more here than any document.

The survey before the first change

Anyone taking on an unfamiliar project should read it first rather than touch it. Sensible questions for a first review: which core version is running, and how long will it be maintained? Which extensions are installed, which are actually used, which are orphaned? Is the installation managed with Composer or grown by hand? Is there a sitepackage, or are templates scattered? Does version control exist, and is its latest state also the state on the server?

That last point is the most common finding. When something different is running live from what the repository says, every change is a risk until the difference is understood. How to judge the version level afterwards is covered in when support ends.

Parting fairly pays off

A change of agency is not a verdict on the previous work, and treating it as one helps nobody. The old agency holds the only complete body of knowledge about the project; pushing them into a defensive stance costs weeks of reconstruction.

A sober sequence works well: notice given in writing and on time, a handover list with a realistic date, a joint session for questions, a clear statement on how long the old team remains responsible. After that the change is an administrative matter rather than a dispute.

When changing is a bad idea

In the middle of a running project with a fixed deadline a change is expensive, because the learning curve comes on top. The same applies when the real conflict is an unclear brief: anyone who cannot say what they expect will get the same result from the next agency. What to look for in that choice is covered in choosing a TYPO3 agency.

And sometimes a conversation is enough. Two out of three reasons on the list above can be resolved with a clear agreement on availability and responsibility, without anyone switching providers.