How a Small Studio Rebuilt Its Stack Without Stopping Client Work

This demonstration case study describes a fictional composite project.

The studio's technical stack had not failed. That was the problem.

Projects still shipped. Client sites stayed online. Invoices went out and the team could usually find the latest file after asking in the right channel. Nothing was broken enough to justify stopping paid work, yet almost every delivery carried a small tax imposed by tools chosen at different stages of the studio's growth.

The seven-person team used one system for proposals, another for project plans, two places for credentials and a deployment process whose safest description was “ask whoever worked on the last one.” Its oldest client projects depended on conventions nobody would choose today. Its newest projects used a cleaner approach, but only two people understood it well enough to intervene when something went wrong.

A dramatic rebuild would have been satisfying and commercially reckless. The studio could not pause projects while it redesigned its internal machinery. It needed to change the stack in the same hours used to keep the old one running.

Why the old stack could not change at once

The first proposal was a migration weekend. Everybody would prepare on Friday, move active work on Saturday and start Monday inside a unified system. It had the emotional appeal of clearing a crowded desk in one sweep.

It also treated the stack as a collection of files rather than a collection of working agreements. Moving a repository is easy. Moving the unwritten rule about which branch a freelancer may deploy, the reason one client receives a manual preview or the sequence an account manager follows before a launch is not. Those details reveal themselves during work, not during an inventory.

There was a second risk. A weekend migration creates a single point at which many unfamiliar systems become production systems together. When Monday arrives, every problem competes for attention at once and the old path has often been dismantled before the new one has earned trust.

The team rejected the clean break and set one constraint instead: no client deadline would be moved to make the migration look orderly. If a new process could not coexist with delivery, it was not ready to replace the old one.

The studio stopped treating migration as an event and started treating it as a second, temporary product with its own users, risks and release sequence.

Map the work before choosing replacements

The team spent its first week documenting handoffs rather than comparing products. Each person took one recent project and traced what had happened from signed proposal to final deployment. They recorded where a decision changed hands, where information was copied and where somebody relied on memory.

This produced a map that looked different from the studio's list of subscriptions. Several expensive tools were barely involved in delivery. A plain shared document carried most client approvals. The most fragile step was not technical at all: credentials were requested late because responsibility for collecting them shifted between the account lead and developer depending on who noticed first.

The map separated three kinds of change:

• Replace now: low-risk internal processes with clear owners and no direct effect on client systems.
• Move with the next project: workflows that could be introduced cleanly at the start of new work.
• Leave until renewal or closure: legacy infrastructure where migration risk outweighed the immediate benefit.

This prevented the stack from becoming a shopping exercise. A new tool was considered only after the team could name the handoff or failure it was meant to improve. If the problem was unclear ownership, buying a more capable interface would not solve it.

The resulting plan was smaller than expected. The studio needed one reliable project record, a standard repository structure, an owned credential store and a repeatable deployment path. Several other tools could remain for the time being because they were inconvenient rather than dangerous.

Build a parallel path

The first replacement was the project record. Instead of importing every historic conversation, the team created a compact template for active facts: scope, decision log, owners, environments, credentials location and next client approval. One ongoing project was copied into it manually. The old planning system remained available and authoritative until the account lead confirmed that nothing required for delivery was missing.

The same parallel approach was used for repositories and deployment. A template defined folder structure, environment variables, preview behaviour, production approval and rollback. New projects received it automatically. Existing projects moved only when they entered a meaningful new phase, such as a redesign or hosting renewal.

Running two paths was temporarily less efficient. People checked both systems, and a few updates had to be copied. That duplication was intentional. It created a period in which discrepancies could be found without turning them into client incidents. The old path acted as a reference while the new one proved that it contained the work's actual requirements.

Ownership was made explicit at each stage. One person maintained the project template, another the deployment process and another the credential policy. Ownership did not mean doing every task. It meant being responsible for answering why the process worked as it did and deciding when a proposed exception belonged in the standard.

The studio also kept a migration log with three short fields: what moved, what surprised us and what should change before the next move. This became more useful than the original plan. Assumptions were corrected while they were still small, and the process evolved from observed work rather than from a diagram made before anyone had used it.

Move one live project all the way through

After the internal pieces had survived several weeks, the team selected a modest new client project as the first complete test. It was real enough to expose pressure but contained no unusual infrastructure or fixed launch event. The client was not asked to participate in the experiment; externally, the studio's communication and commitments remained the same.

The project revealed friction that test runs had missed. The repository template assumed the person creating a preview also had access to production. The approval record did not distinguish between permission to review copy and permission to launch. A designer working outside the development system could see a preview but not the decision explaining why an image had changed.

None of these problems required abandoning the new path. They required making the hidden agreements explicit. Preview access was separated from production access. Approval states were named. Design decisions were linked from the project record rather than buried in a specialist tool.

The team rehearsed failure before launch. A developer who had not built the project followed the deployment notes, stopped the release and restored the previous version. The exercise found two commands that were obvious only to their author and one credential whose ownership still belonged to a personal account. All three were corrected before they mattered.

This rehearsal changed the success criterion. The question was no longer whether the new stack allowed the primary developer to ship faster. It was whether another person could understand the state of a project, make a safe change and recover without an oral history from whoever happened to be online.

Retire the old path deliberately

Old systems linger because “still available” feels safer than deletion. In practice, two possible sources of truth create their own risk. Once the pilot project closed, the studio set retirement conditions for each replaced system: all active records accounted for, exports stored in an agreed location, links redirected where possible and a named date after which no new information could be added.

Nothing was deleted for the sake of tidiness. Read-only archives remained where contractual or historical material might still be needed. What disappeared was ambiguity about where current work belonged.

The studio did not end with a perfect stack. Two legacy projects still used the old deployment path because moving them offered little benefit before their planned retirement. One client continued to approve work through its own portal. The difference was that these exceptions were named, owned and bounded. They no longer looked like accidental examples of the standard.

The migration took place across ordinary project weeks, which made it slower on a calendar and safer in practice. Every new convention encountered real work before becoming mandatory. Every old system remained available until its replacement had carried a complete responsibility. Client delivery continued because the migration plan accepted delivery as a constraint rather than treating it as an interruption.

That is the less cinematic way to rebuild a stack: map the work, replace one boundary at a time, preserve a route back and retire ambiguity only after the new path has earned trust. The studio never had a morning when everything felt newly transformed. It had a series of Mondays on which fewer parts of the work depended on asking the one person who remembered how they used to be done.