An isolation model you can defend
Pool, silo, or a bridge between them, chosen per data store rather than for the whole product. Enterprise buyers will ask how their data is separated, and the answer needs to survive a security questionnaire.
Platform
SaaS transformation
One deployment per customer works until customer forty. Then onboarding needs an engineer, upgrades take a week, and nobody can tell you what a single account costs to serve.
Multi-tenantMeteringSelf-serve onboarding
What is SaaS transformation?
SaaS transformation turns a product deployed once per customer into a single multi-tenant platform. It covers the tenant isolation model, onboarding that runs without an engineer, usage metering per tenant, and cost attribution that turns one AWS bill into a per-customer number.
The problem
The copy-the-stack model has a ceiling
It is a reasonable way to get the first customers live. It stops working when patching means touching thirty environments, when a sales demo needs a provisioning ticket, and when finance asks for gross margin per customer and the only honest answer is a shrug.
50+
SaaS migrations
3
isolation models supported
1
deployment to patch
What you get
Included in the engagement
Tenant onboarding without a human
Signup creates the tenant, the schema, the limits and the billing record. If a sales engineer has to run a script, it is not done.
Metering and usage
Usage recorded per tenant at the point it happens, so pricing changes are a config change rather than an engineering quarter.
Cost per tenant
Tagging and attribution that turns one AWS bill into a per-customer number. This is the report that changes pricing conversations.
Noisy-neighbour protection
Per-tenant rate limits, query timeouts and connection caps, so one customer's bad report does not become everyone's incident.
How it runs
How a SaaS transformation runs
The isolation decision comes first because everything after it inherits the answer.
Pick the tenant model
Pool, silo or bridge, decided per data store and written down with the reason. Reversible later only if the tenant abstraction goes in first.
Thread tenant context
Tenant identity carried through the code and enforced at the data layer, so isolation is not a convention every developer has to remember.
Self-serve onboarding
Sign-up to a working tenant with no human in the loop, including what happens when a step fails halfway.
Metering
Usage recorded per tenant at the point it happens, whether or not you bill on it yet. This is the one thing you cannot backfill.
Cost and limits per tenant
Spend attributed per tenant, plus quotas and throttles so one customer cannot eat another customer's capacity.
Fit
Who this is for
If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.
- You run one environment per customer and onboarding takes days.
- An enterprise deal is blocked on a data-isolation answer.
- You want usage-based pricing and the data to support it does not exist.
Do we have to rewrite the application?
Usually not all of it. The changes concentrate in authentication, the data access layer and provisioning. We stage it so the existing single-tenant deployments keep running while the shared platform comes up beside them.
How do existing customers move over?
One at a time, smallest first, with the old environment left standing until the new one has run a full billing cycle.
What happens to per-customer customisations?
They get sorted into configuration, feature flags, and the handful that are genuinely bespoke code. The first two move to the platform. The third is a commercial conversation, because carrying them forever is what made the single-tenant model expensive.
Can we still offer a dedicated deployment to large customers?
Yes, and that is the bridge model. Most tenants share the pool, the customers who pay for separation and ask about it in the security review get their own store, and both run from the same codebase and the same deploy.
How do we work out what to charge once usage is metered?
Metering comes first, pricing second. Run the meters for a billing cycle or two, look at cost per tenant against what each one pays, and you will usually find the shape of the pricing model in that data rather than in a workshop.
How long does the transformation take?
The platform work is typically a few months before the first tenant runs on it, then customers move over on their own schedule. It runs beside the existing deployments the whole time, so there is no window where you cannot ship.
Reference
The AWS documentation we work from
Related
Work that usually comes with this
Multi-tenant web apps
Pool, silo and bridge tenancy models on AWS, with per-tenant limits, isolation you can prove to an auditor, and cost attribution that adds up.
ArchitectureRead more
Modern app development
Containers on EKS or ECS, microservices where they earn their keep, and enough observability to debug the system at three in the morning.
BuildRead more
Compliance and security
IAM cleanup, encryption, audit trails and the evidence collection that turns a SOC 2 or ISO 27001 questionnaire into a short afternoon.
SecurityRead more
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.