Isolated Databases Per Customer, Onboarded in Two Weeks
A multi-tenant data platform where nothing is shared between customers: not a schema, not a server, not a line of transformation logic. Bringing a new customer live went from about two months to about two weeks with the isolation model intact.
- Data Engineering
- Multi-Tenant Architecture
- Microsoft Azure
- Regulated Environments
- 2 weeks
- To bring a new customer environment liveDown from about two months for the same work: a fully isolated environment provisioned, its extraction and transformation logic written against that customer's real data, and its first-day validation signed off. Observed across successive onboardings by the delivery team rather than instrumented.
- Zero
- Data paths between customer environmentsNo shared schema, server, database or transformation procedure. Two components are deliberately shared and neither carries customer data: group identity configuration, and an alert dispatcher that holds no database connections and receives only parameters.
- 100+
- Transformation procedures per environmentMaintained per customer rather than once, which is the accepted cost of the isolation model, and executed in the same designed sequence of serial and parallel blocks at every customer.
Overview
If you sell software into a regulated industry, your customers probably refuse to share an environment. Hospitals ask whether their patient records sit in a database next to another health system. Banks ask the same about account data. Defense and public sector buyers ask before the conversation reaches pricing.
So you give each customer its own. It wins deals. Then onboarding becomes a project rather than a deployment, environments drift apart, one fix has to be written and released several times over, and delivery capacity rather than sales decides how fast the company can grow.
This platform runs a complete estate per customer: separate resource groups, a dedicated managed SQL instance, its own storage, orchestration, identity and stored procedures. Bringing a new customer live originally took around two months. It now takes about two weeks, and the isolation model is completely intact.
The Context
The client is not named. It is a healthcare technology company selling clinical operations and revenue cycle software to hospital systems in the United States, running on Microsoft Azure.
The software supports decisions around surgical services. Operating rooms are among the most expensive resources a hospital runs, staffed by the costliest clinical teams, scheduled by the minute, and impossible to recover once idle. A room sitting empty at eleven in the morning is not a cost that can be earned back at three in the afternoon. That puts a hard requirement on the data underneath rather than on the dashboard above it.
The Challenge
Isolation wins the deal and then becomes the constraint. The symptoms are consistent wherever this pattern is in place, and a business hitting three of them is already carrying the condition rather than the risk.
- Onboarding a new customer is a project rather than a deployment, and the estimate is never right
- Environments have drifted apart, so one fix has to be written, tested and released several times over
- Nobody can say with confidence that customer six is configured the same way as customer two
- The pipeline works until real customer data arrives, and then the first two weeks are firefighting
- A number looks wrong and nobody can tell whether the cause was the data, the transformation, or a file that only half arrived
- Delivery capacity, not sales, decides how fast the company can grow
The way out is not abandoning isolation. It is being precise about which parts of a customer environment are genuinely allowed to differ, usually the data and the logic that touches it, and industrializing everything else.
What Was at Stake
A customer who is not live is not paying, and delivery capacity is the ceiling on how fast a sales team can move. Six weeks earlier per customer changes what a business can sell.
The data underneath carries a second cost that does not appear on a delivery plan. A predicted case duration that is wrong does not just look bad on a dashboard, it puts a surgeon in a room that is not free. A missed documentation field is revenue the hospital never collects. And running billing or prediction workloads against a half built analytics layer throws no error at all: it produces output that looks entirely plausible and is wrong, which is the most dangerous failure mode in any analytics platform, because nobody notices.
Our Role
The work spans disciplines that are usually bought separately and then fail to join up. Here they operated as one delivery group alongside the client's own product engineering, quality assurance and domain leadership.
- Cloud engineering: infrastructure as code in Bicep, a landing zone per customer, identity architecture on managed identity, and scheduled scale up and scale down for cost
- Cloud security: the isolation model, IP restricted ingress, key management, ticketed access governance, continuous compliance monitoring and penetration test remediation
- Data engineering: ingestion and orchestration design, a transformation layer of more than 100 procedures per environment, data quality and cleansing, index and performance strategy, and source side extraction scripts written against each customer system
- AI engineering: production AI workloads running on regulated data, plus internal tooling that reduced delivery effort
- Delivery discipline: a written onboarding runbook with evidence capture, a fixed operating contract, per customer alerting, and a reference build model
Where the Time Went, and How It Was Cut
Four things compressed the timeline and they did different work. The attribution matters more than the headline, because copying the wrong one produces no change.
Infrastructure as code removed the build
Bicep templates held in version control, a branch per customer, and only the parameter changes that customer genuinely requires. Orchestration pipelines are exported and redeployed as ARM templates. The estate is described rather than clicked, so it can be reviewed, diffed and audited. This had little effect on the timeline, because provisioning was never where the time was going.
Internal AI tooling removed engineering effort
SQL work runs through internal assistants connected to the database estate, prior scripts, schema history and pipeline monitoring, under read only access scoped to each engineer's own permissions. This took a full onboarding from roughly two months to one.
A reference build removed the rediscovery
The first customer within a parent organization is the expensive one. Once its transformation logic has absorbed that organization's data conventions, every subsequent site starts from a build where those problems are already solved. Procedures are copied and adapted rather than shared, so isolation holds and only the thinking is inherited. This is the single largest contributor to the two week figure.
A runbook removed dependence on memory
Eleven stages, from confirming naming standards through to day one validation and sign off, each with a checklist, required evidence and a place to record what was actually deployed. Little effect on the timeline; it is why onboarding is a process the organization owns rather than knowledge a few individuals carry.
The part that stays hard is not infrastructure. No two customers record their operations the same way, so extraction logic can only be finished once live data starts arriving and the team can see what actually came out. The variance lives in the customer, not in the code. What can be shortened is the loop, and what can be eliminated is rediscovering a problem already solved somewhere else.
What Stops the Environments Drifting Apart
The shape of every customer environment is identical even though the contents differ. The pipeline is a fixed contract, run in the same order everywhere, and that order does not change without a design review.
One sealed estate per customer
Separate resource groups for development and production, a dedicated SQL Managed Instance carrying staging, operations, analytics and billing reporting databases, and its own storage account, key vault, orchestration instance, user assigned managed identity, database security group and telemetry workspace. A compromised identity cannot authenticate outside its own resource group.
- Resource groups
- SQL Managed Instance
- Key vault
- Data Factory
- Managed identity
One inbound path
Data leaves the customer estate before it reaches the cloud. Extraction scripts run on the customer's own infrastructure, written against that customer's system configuration, and write delimited files daily to an SFTP endpoint on its storage account: IP allowlisted, soft delete enabled, key pair authentication.
- SFTP
- IP allowlisted
- Key pair auth
Five stages, in the same order, everywhere
Landing loads delivered files to staging, normalizes empty strings, archives to a date partitioned folder and clears the extract path. Transformation runs more than 100 stored procedures in a designed sequence of serial and parallel blocks. Metrics are calculated by a Python function app on durable orchestration. Analytics shapes and pushes the portal ready data set. Only then does the parallel block run.
- Landing
- Transformation
- Metrics
- Analytics
- Parallel block
One enforced dependency
Report distribution, billing processing and machine learning scoring run only once the analytics stage has fully completed. That dependency is enforced rather than assumed, because running them against a half built analytics layer produces confident numbers that nobody has any reason to question.
Controls that came from something breaking
None of these were in the original design. Time based triggers were replaced with a ten minute poll on the inbound path, because files do not arrive when a clock says they should. File counts are checked before processing, because a partial delivery looks exactly like a complete one. Duplicate detection was added after duplicates silently inflated results. Cleansing logic handles malformed values rather than propagating them into the gold layer. Long running prediction steps were re-architected onto durable orchestration. Index strategy was reworked and a scheduled rebuild became standing.
- Arrival poll
- Completeness check
- Duplicate detection
- Index rebuild
Two deliberate exceptions
Claiming total isolation where it is not true is worse than not claiming it, because a security reviewer will find the exceptions anyway. Where a customer group operates under one corporate domain, identity configuration lives in a resource group serving that group. One scheduler machine runs notification code for every customer, in a per customer folder, on cost grounds. It holds no database connections and no regulated data: it receives parameters and dispatches alerts.
Orchestration signals cross the boundary. Customer data never does. The distinction between sharing infrastructure and sharing data is the one that matters, and the one a buyer's security reviewer will go looking for. Every exception in an estate should have an answer that short.
What We Delivered
What the organization owns at the end, rather than what a few people know.
Templated infrastructure
Bicep templates in version control with a branch per customer, and orchestration pipelines exported and redeployed as ARM templates, so an environment is reviewable and auditable rather than clicked together.
An eleven stage onboarding runbook
Checklists, required evidence, and a record of what was actually deployed at each stage through to day one validation and sign off.
A reference build per customer group
Every control now runs at every customer, including customers onboarded long after the failure that caused it. A new environment does not start from a clean design; it starts from a pipeline already hardened by every previous customer's worst day.
Per customer alerting
A dedicated alert channel per customer, wired into the failure path of every pipeline through global parameters, so a failure surfaces against the right account immediately rather than being found in a log later.
A day one validation sequence
Per customer data volume comparison against the reference build, with enforced pipeline gating before downstream workloads are allowed to run.
Cost controls
Scheduled scale up and scale down functions that release compute when it is not needed, per environment.
Outcomes
Three figures are published for this engagement, each with what it was measured against. The timeline figures are observed across successive deliveries by the team that did the work rather than instrumented measurements, and are described that way here because they are described that way in the engagement record.
- A new customer environment goes live in about two weeks rather than about two months
- Problems concentrate in onboarding and stabilization and largely stop once a customer is live
- A customer wanting its own metric definition or a bespoke report can have it, with no release that touches anyone else
What does not scale is named as clearly as what does. Per customer transformation logic grows linearly and does not compress. Beyond a few dozen customers the fork per customer model needs to give way to a shared transformation core with per customer configuration and mapping overlays, which preserves the data isolation a regulator and a buyer care about while collapsing the logic duplication only engineering pays for. That transition is a decision best made deliberately rather than discovered at the point of pain.
What This Page Does Not Cover
Published in anonymized form. Client identity is withheld, and clinical and financial results at individual hospital sites are held by those institutions rather than reported here.
- Client identity, its customers, and the size of the estate
- Volumes, transaction counts and data retention
- Any business or clinical outcome at a customer site
- The source system each customer extracts from, and its configuration
- Validation today rests on a documented day one sequence, volume comparison against a reference build and enforced pipeline gating rather than on a mature automated test suite. Automated regression testing is being introduced across the estate; that gap is named here rather than hidden, because it would be found in week two of any engagement anyway
Related Capabilities
The disciplines this engagement drew on, and where each is described in full.
Data Engineering & Machine Learning
Ingestion, orchestration, a transformation layer per environment, data quality and the index strategy that keeps it fast as history accumulates.
Data engineering and machine learningCloud Infrastructure
Infrastructure as code, a landing zone per customer, identity architecture on managed identity, and cost controls that release compute when it is idle.
Cloud infrastructure engineeringCloud Security & Compliance Readiness
The isolation model itself, restricted ingress, key management and ticketed access governance, plus the evidence a procurement reviewer asks for.
Cloud security and compliance readinessEngineering Teams & Managed Delivery
A written operating contract and runbook, so onboarding is a process the organization owns rather than knowledge a few individuals carry.
Engineering teams and managed delivery