On Salesforce's Force.com platform, a customer's custom objects and fields are rows of metadata in shared tables rather than a schema of their own (Weissman and Bobrowski described the design at SIGMOD in 2009). What does that remove from the legacy problem, and what does it not remove?

What they chose

Rather than give each tenant a database or a schema, the platform stores tenant data in shared tables keyed by an organisation identifier, with wide general-purpose columns, and describes every custom object, field and rule as metadata the runtime interprets. Creating a custom field runs no schema change on the database; it inserts a row in a dictionary.

What it removes from the legacy problem

The dominant cause of legacy pain in packaged enterprise software is the version fork. A customer installs version 6, customises it, declines three upgrades because the customisations would break, and ten years later is running a variant that only they have, on a release nobody supports, with no path forward that is not a project.

A metadata-driven multi-tenant platform makes that structurally impossible. Everyone is on one version of the code because there is only one deployment of it, so upgrades are not a customer project and there is no accumulated gap to close. The second gift is assessability: because customisation lives in queryable metadata, "how much have we customised" is a question with an answer, which is exactly the question an on-premises legacy assessment cannot answer without months of archaeology.

What it does not remove

• The customisation becomes the legacy. Ten years of declarative automation, triggers, validation rules and integrations accumulate, nobody owns the whole of it, and it has the same property as legacy code: changing it is risky because nobody knows what depends on what.
• The platform's limits become your architecture. Governor limits, shared-tenancy performance ceilings and interpretive overhead are constraints you cannot engineer around, only design within.
• Regression risk moves to you, on the vendor's schedule. You cannot decline an upgrade, so the work shifts from "plan a migration" to "keep a regression suite green against releases you do not control". That is a better problem, and it is not no problem.
• Exit becomes the hard migration. Data is queryable but the behaviour lives in platform-specific metadata that has no equivalent elsewhere.

Where copying it would be a mistake

Do not build a metadata-driven platform to serve twenty tenants. The design pays for itself when per-tenant schema changes are operationally impossible — thousands of tenants, one deployment, upgrades applied to everyone at once. Below a few hundred tenants, a schema or a database per tenant is simpler, debuggable with ordinary tools, and lets a large customer be isolated or migrated individually. The interpretive layer is a permanent tax on every query and every developer who has to reason about it.

When this is the wrong answer

For an assessment, the useful transfer is the question rather than the architecture: can you enumerate your customisations, and can you take a vendor release without a project? If the answer to both is no, that is the finding, and it holds whether the system is a SaaS platform or a twenty-year-old on-premises suite.

Common weak answers

• "Multi-tenancy is about saving infrastructure cost." The density saving is real and secondary. The decisive property is that there is one version of the code to maintain.
• "So SaaS means no legacy." It moves legacy from code and version to configuration and process. Organisations with a decade on one platform have legacy assessments to do, just about different artefacts.