Here's a pattern that plays out on almost every enterprise application in existence, eventually:
A business change lands. A new approval step, a renamed field, a re-shaped workflow, a different classification scheme for incoming work. The people who need the change want it now. The people using the current version don't want their day interrupted. The team that would ship the change has to choose: a maintenance window (painful), a feature flag tangle (messy), a forked dev environment (diverges from prod in 48 hours), or a months-long "v2 project" that ships everything at once under a lot of stress.
None of these are good answers. They're what you do when your platform doesn't give you a better one.
What we wanted instead
We wanted a simple property: two versions of the same app, running at the same time, on the same database.
Production users stay on v1. Your team tests v2 in preview. When v2 is ready, you promote it - one click - and the next-signed-in user is on the new version. v1 keeps running for users who haven't finished a session yet.
Everyone's looking at the same underlying data. Everyone has the permissions they should. Nobody's interrupted. Nothing's in a half-migrated state.
If that sounds obvious, it is. It's also surprisingly rare. Most low-code and enterprise platforms ship "versions" that really mean "snapshots you can restore" - not "alternative configurations that can run side-by-side pointed at the same data".
Why it's harder than it looks
The reason most platforms skip this isn't that they don't see the value. It's that the engineering is genuinely hard, and most platforms got their first architecture wrong for it.
Running two versions side-by-side requires the platform to answer a lot of questions cleanly:
- What's versioned? The data model? The pages? The permissions? The workflows? All of it, atomically?
- What's shared? If two versions point at the same data, but v2 has a new field, what happens when v1 reads a record that has it? What happens when v2 reads a record that predates it?
- How does a user know which version they're on? And how do they switch - or opt out of preview, or get shifted to v2 when v1 is deprecated?
- What about in-flight work? Someone started an approval on v1 twenty minutes ago. v2 changes the approval chain. What happens to their workflow?
- Who decides? Admins? End users? Both?
Each of those questions has a right answer, a wrong answer, and a dozen misleading ones. If you don't answer them consistently from the first commit, they'll compound into an architecture you can't ship parallel versions on without rebuilding.
What xMS does
In xMS, every piece of app configuration - every resource, field, role, page, permission, menu, workflow - is tied to a specific app version via a composite identity. Create a new version and the entire configuration is cloned. Edit the clone freely while production stays untouched.
A few concrete behaviours that fall out of this:
- Finalised versions are immutable. Once v1 is locked, nothing can change it. Your production app can't drift mid-week because someone edited it on a train.
- Data is shared across versions. One underlying
data.*schema holds the records. The version-specific metadata determines which fields, permissions, and pages each user sees - but the records themselves are singular and real. - Versions deploy to environments with access levels. A single environment (say, "staging") can have v1 deployed as
public(visible to everyone) and v2 deployed aspreview(visible only to explicitly opted-in users). One click to promote v2 to default; another click to sunset v1 and gently move stragglers. - Users can switch. Preview users see a version switcher in their app. They can opt into v2 for a session, compare behaviours against v1, and tell you what's broken - without leaving their normal workflow.
- Rollback is a version switch. Because promotion is just "change which version is
default", going back to v1 is trivially symmetrical to going forward to v2. It's the same operation.
What this actually unlocks
The version primitive is one of those things where the platform capability doesn't feel very interesting until you live without it. Once you have it, whole categories of operational pain disappear:
- Bring a new workflow online gradually. Promote v2 to a single pilot user, then a pilot team, then a department, then everyone - without branching code, without running two copies of the application.
- Train teams on the new version before cutover. Your trainers work in v2. Your users stay on v1. Cutover is calendar-based, not technical.
- A/B test business logic. Run two versions of an approval chain side-by-side for a month. See which one clears faster, which one gets fewer rejections, which one hits the SLA.
- Change safely under high regulatory scrutiny. Any change that touches compliance can be run as v2 in preview, reviewed by compliance, signed off, and promoted - with a full audit trail of the exact configuration the regulator approved.
- Support during transitions. The help-desk team can drive v2 while regular users are still on v1, reproducing bugs with the user's permissions preserved via the impersonation tooling. No "please describe what you're seeing on your screen" back-and-forth.
The point
"Versioning" on most platforms means "a backup you can restore if something breaks". On xMS, versioning means "a live parallel configuration you can selectively run against your real data."
Those are two different products built on top of the same word.
When enterprise buyers ask us "how do you handle change management?", we don't talk about maintenance windows or release trains. We show them two versions of an app running in the same window, pointed at the same records, with different users seeing different fields. Because if you've wrestled the change-management problem on traditional enterprise apps for a decade, what you want isn't a better process. It's a platform where the painful parts of the process are things you don't have to do.
That's the version story. Or maybe two of them.