AccAnalysisAccAnalysis
Enterprise IT & Cloud

An internal tool, turned into something the company could sell

A company had built a good internal system, but its simple authentication made multi-tenancy impossible — so it could not be sold as a service. We modernised the identity layer and supported the launch.

At a glance
Status
Delivered
Region
Japan
Engagement model
Dedicated team

Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.

The organisation

Context

A company running a capable on-premises system it had built for its own operations.

It had a commercial opportunity to offer the same system to others — but the system had been built for one organisation, and its authentication assumed exactly that.

The brief

The problem

  • Authentication was simple by design, because it had only ever needed to serve one organisation.
  • Without identity and permission separation between tenants, multi-tenancy could not be offered safely at all.
  • Selling a system per client would have meant one deployment per client, which does not scale commercially.
  • Prospective customers expected their own subdomain, and some expected their own domain entirely.
The work

What we built

A modernised identity and permission layer

Migrating authentication and authorisation onto dedicated identity services capable of expressing tenant boundaries.

Multi-tenancy

With identity, permission and data separation between tenants.

Client-specific subdomains

And support for customers using their own company domains.

Ongoing support through the launch

Because moving from an internal tool to a commercial service raises operational questions the original build never had to answer.

Method

How we delivered it

  1. 1

    Model the tenancy boundary

    What is shared, what is separated, and what must never cross. Decided before any migration, since it is expensive to change later.

  2. 2

    Stand up the identity services

    Alongside the existing authentication.

  3. 3

    Migrate authentication and authorisation

    With the existing users moved without a reset.

  4. 4

    Add tenancy to the application layer

    Tenant-scoped throughout.

  5. 5

    Add subdomain and custom-domain handling

    Then support the commercial launch.

Sequence

How it was phased

PhaseDurationWhat happens
1Tenancy modelling
2–3 wks

Boundary design, shared versus separated, migration plan

2Identity services
3–4 wks

Deployment alongside the existing authentication

3Auth migration
3–4 wks

Authentication and authorisation moved, users migrated

4Tenant scoping
4–5 wks

Application-layer tenancy, data separation

5Domains & launch support
3–4 wks

Subdomains, custom domains, launch operations

Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.

Hand-over

What the client keeps

  • The identity configuration and its source
  • The tenancy model as documentation
  • Migration scripts
  • Domain-handling configuration
  • Operational runbooks
Stack
Ory KratosOry KetoMulti-tenant application architectureSubdomain and custom-domain routingContainerised deployment
Keep reading

Related

Related case studies

Tell us what your current system can't do, and we'll tell you what it would take to change that.