Rebuilding a single-tenant freight platform as multi-tenant SaaS

The provider had grown by saying yes. Every early customer got a deployment of its own, and most got a few bespoke changes with it. Five years later that meant forty-one production environments, each on a slightly different version of the codebase, several with customer-specific branches that had never been merged back.

Onboarding a new customer took around three weeks of engineering time, which put a hard ceiling on sales. The company could not close deals faster than it could provision them, and the provisioning work fell on the same engineers who were meant to be building the product.

Shipping a feature meant deciding which of the forty-one environments should receive it and when. In practice most received it late or not at all, so the product the sales team demonstrated and the product most customers actually used had quietly diverged.

Infrastructure cost scaled linearly with customers rather than with usage, because every tenant carried an idle baseline of its own. Gross margin was moving in the wrong direction at exactly the point investors were looking at it.

The objectives were straightforward and hard: consolidate to a single multi-tenant platform, keep every existing customer live throughout, reduce onboarding to a self-service action, get to one release train, and preserve the genuine customer-specific behaviour that was worth keeping while retiring the rest.

The first phase was not engineering. It was a systematic diff of all forty-one deployments to separate real product variation from accumulated drift. Around a fifth of the customer-specific code turned out to be configuration in disguise; most of the remainder was dead, superseded, or duplicated.

That analysis produced the tenancy model. Genuine variation was reclassified into three tiers: tenant configuration held as data, feature flags held per tenant, and a small set of extension points where a customer could genuinely need different behaviour. Anything that did not fit one of those three was either brought into the core product or retired with the customer’s agreement.

The platform was then rebuilt as a shared application tier with tenant-scoped data isolation, tenant context resolved at the edge and carried through every layer, and per-tenant rate limiting so one customer’s integration load could not degrade another’s experience.

Migration ran one tenant at a time, smallest first. Each tenant was replayed onto the new platform in parallel with its existing deployment, with data and outputs compared before any traffic moved. No tenant was cut over until its own data reconciled.

Onboarding became a provisioning workflow rather than an engineering task: create tenant, apply configuration profile, load reference data, invite users. The three-week engineering effort became a form.

Alongside the platform work, the delivery model changed. Trunk-based development with feature flags replaced long-lived customer branches, and a continuous delivery pipeline with automated tenant-aware test suites made a single weekly release across all tenants a routine event rather than a risk.