Redesigning a live CRM operators depend on, without a rollback

Co-Founder, Dabster Labs · Client engagement, anonymised at the client’s preference

A Cyprus regulatory-training provider now runs its self-hosted CRM on a premium interface, and it went live cleanly on the first try after two earlier attempts had to be pulled back. The change that made the difference was not the design. It was building a safe place to see and correct the design before it ever touched the system the team uses every day.

The situation

The self-hosted open-source CRM looked dated. Operators depend on it daily, so the interface is not cosmetic, it is the tool they work in. Two earlier reskin attempts had already been rolled back, because there was no safe way to see and iterate the interface before pushing it to the live system. Every change was a guess made straight against production, and when a guess looked wrong in real use, the only option was to revert.

What we built

First, a faithful local copy of production: the real database dump, the real custom code, and every module switched on. That copy behaves like the live system, so the interface could be seen and iterated through automated browser screenshots before anyone touched production.

On that copy we built the premium skin: navy chrome, solid-orange active navigation pills, and styled content surfaces across cards, lists, forms, buttons, badges and tabs, with gradients, shadows, custom scrollbars and hover motion. Three real bugs surfaced on the copy and were fixed there, not in front of operators: a right-hand column that rendered black and unreadable for anyone whose machine was set to dark mode, uneven gaps in the agenda menu, and truncated sidebar labels.

Only then did it go to production, as configuration only, with no core files patched. The switch-on was backed by a byte-exact in-database backup of the previous state and one-command deploy and rollback scripts. Every major page was verified to return a clean HTTP 200: home, dashboard, the project and ticket lists, the agenda and the admin screens.

What changed

• The dated interface became a premium one, without a single core file being patched.
• Three real bugs were caught on the local copy instead of by operators: the black dark-mode column, uneven menu gaps and clipped sidebar labels.
• The reskin shipped cleanly this time, after two earlier attempts had to be rolled back.
• Reverting is now one command, and the pre-change state is preserved byte-for-byte in the database, so future iterations carry no risk to the live system.

How it works

The local copy mirrors production exactly, same data, same custom code, all modules on, so what you see there is what operators will see. An automated browser (Playwright) drives the interface and captures screenshots on every iteration, so the look can be reviewed and corrected before anything goes live. Bugs tied to a specific setup, like the dark-mode column, are reproduced deliberately by pointing the browser at dark mode. When the skin is ready, it ships to production as a configuration value rather than a file edit, so there is nothing to un-patch, and the whole change can be undone with a single command against a byte-exact backup.

Where it stands

Live in production. The premium skin is serving on every page, all major pages return a clean HTTP 200, and the local copy plus the deploy and rollback scripts stay in place, so the next round of changes can be tried safely before it reaches the people who rely on the system.

If a system your team depends on every day needs a safer way to change, talk to us.

---

How it works

The CRM is a self-hosted, open-source platform that the operators run every day. The core of that platform, its data model, its business logic, its API, is the part we never wanted to touch. Rewriting it is where the risk lives, and it is also the part that was working correctly. So the redesign leaves the core untouched and changes only the layer the operators actually see.

We treated the interface as an override rather than a rewrite. The platform already exposes hook, substitution, and template mechanisms for changing how pages render without editing the underlying application. We built the new look and the new day-to-day screens on top of those extension points: a small set of custom modules that restyle the existing lists, add the screens operators asked for, and re-present the same records in a clearer layout. The data underneath, the permissions, and the record trail all stay exactly as the platform defines them.

Because nothing in the override forks the core, platform updates and security patches still apply the normal way. A single stylesheet variable block controls the palette and branding, so the visual identity can change without hunting through templates. The result is an interface that looks and behaves like a purpose-built tool while the engine below it remains the stock, supported, self-hosted CRM the business already trusted.

How we shipped it without a rollback

Earlier redesign attempts had to be pulled back after going live. The reason this one did not is structural, not luck: the safety comes from how the change is built, so there was very little that could go wrong at cutover in the first place.

• Nothing to migrate. Because the redesign is an override on top of the untouched core, going live means switching on the new interface modules, not moving, transforming, or rewriting any data. The riskiest part of most cutovers simply is not present here.
• Single-step revert. The core, its data, and its record trail are never modified, so backing the interface out is a matter of disabling the new layer and falling straight back to the stock platform, with no data to unwind. A change you can reverse in one step is a change you can ship with confidence.
• The platform’s own rules still hold. Permissions and the record trail keep being enforced by the platform underneath, so the redesigned layer cannot quietly change who sees what.
• Repeatable, scripted install. The interface modules live in version control and are installed by scripted, repeatable steps rather than hand edits on the live box, so what goes to production is exactly what was built.

A reversible change with no data migration is what turns a first-try cutover from a gamble into a safe bet. It went live cleanly on the first attempt, with no rollback.

Built with

• A self-hosted, open-source ERP/CRM platform (PHP) as the untouched core, extended through its own module, hook, and template mechanisms.
• Custom modules for the interface override, the restyled lists, and the operator-facing screens, kept in version control so the redesign is reproducible.
• MariaDB as the underlying database, unchanged by the redesign.
• Python for the supporting automation and data scripts.
• Docker for the packaged stack, with a reverse proxy terminating TLS in front of the application.
• Bash deploy scripts and cron for repeatable, scripted setup and scheduled jobs, run first on a staging mirror and then in production.
• EU-hosted infrastructure, with secrets kept out of version control in a locked-down environment file.

Related service: CRM Integration