Simple Merge
Plan, Govern, and Execute the Technology Work Behind Acquisitions and Carve-Outs
For CIOs, IT integration leads, and corporate development teams running acquisitions, divestitures, and carve-outs across Microsoft-centric estates.
Build the estate inventory, reconcile source and target environments, plan dependency-aware migration waves, rehearse cutovers, capture approvals, and preserve the evidence chain in one operator workspace.
None of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.
When you can get Simple Merge
Coming soonNot open yet. Tell us where to send word when it is.
What you can do now
Request early access Volunteer to beta test Get product updatesNone of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.
Where this stands
- Availability
- Coming soon
What it costs
No published price yet. Pricing is set before this product opens.
Routes that are not open
- Direct trial with Simple Intelligence Not open yet
- Direct subscription from Simple Intelligence Not open yet
- Microsoft Marketplace Not published yet
- Sponsored subscription for member companies Not open yet
The deal closes on a Friday. The estate does not.
Signing moves ownership. It does not move a mailbox, reconcile two directories, or say which of the four hundred applications on the target side already exist on the buyer side under a different name. That work starts the following Monday, runs for a year or more, and is usually planned in a spreadsheet nobody can audit six weeks later.
Cutovers fail in the plan, not in the execution.
The Saturday night that goes wrong rarely goes wrong because a script failed. It goes wrong because an application was never inventoried, a dependency was never drawn, or a wave moved forty people whose line manager stayed behind in the source tenant. By the time anyone sees the failure, the decision that caused it is three months old and unwritten.
Simple Merge is the workspace for that plan, and this page says how much of it is built.
Discovery, assessment, reconciliation, treatment decisions, the business case, dependency-aware waves, rehearsal, the gates in front of a cutover, the runoff window, and a hash-chained evidence ledger are represented in the current product build for planning, assessment, and rehearsal. Live execution and production validation require adapters that are not available today. Every status word on this page is generated from the same capability registry the product ships with, so a claim here cannot drift away from the code behind it.
Where Simple Merge actually is today.
Simple Merge is planning, assessment, rehearsal, governance and evidence software today. The operator loop runs end to end against a synthetic estate. Nothing on this page describes a change made to a customer system, because the product does not make one yet.
Working today
- Estate inventory per in-scope workload family, matched on the workload and the source record so a second scan corrects the picture instead of doubling it
- Assessment, dependency edges and a treatment recommendation per asset, with an operator override that freezes the row against any later re-run
- Source-to-target reconciliation with a confirm or reject decision per asset, recorded with the person who made it and the reason
- Dependency-aware wave planning against a complexity ceiling, keeping regions apart except where a hard dependency edge forces the grouping and the wave records that it did
- A business case built from rates the operator supplies, exportable for an executive audience
- A cutover that refuses to start on an undecided wave, an unfinished dependency, or an open hold
- A reversal package captured in the same transaction that records a success, and a runoff window that refuses a reversal once it has closed
- A hash-chained append-only evidence ledger whose verifier names the first row that fails to match
- Tenant isolation and assigned-only visibility composed into the query on both doors, the operator interface and the MCP tools
Not yet
- No live adapter. Execution derives a deterministic job identifier carrying a sim- prefix and calls no Graph, Exchange, SharePoint, Azure Migrate or VMware HCX endpoint.
- Discovery populates a deterministic, obviously fictional inventory rather than scanning a real tenant.
- Post-cutover validation depends on live execution and does not exist.
- Approval is per asset on the reconcile grid. Binding an approval to a hash of the exact change set, so that an altered plan invalidates it, is designed and not built.
- Treatment recommendations come from a rule table today. The model that would score each application is not wired up, and every row states its own provenance.
- Asset matching is lexical. There is no semantic matcher, and the page never calls a match AI-scored.
- The six assessment packs are a planned way to scope one engine. None of them is a separate surface in the product today.
- No price is published, no purchase path exists, and there is no Marketplace listing.
Verified against the product on 2026-08-23.
One control plane, twelve stages, run against every workload family.
Ten of the twelve workflow stages are represented in the current product build for planning, assessment, and rehearsal. Live execution and production validation require adapters that are not available today.
The same twelve stages apply to an Exchange estate, an application portfolio, a VMware footprint, and a set of DNS zones. Naming twelve rather than four is deliberate: the places a person has to sign something sit between specific stages, and a four-phase diagram hides them.
-
1
Discovery
Build the estate inventory per in-scope workload. Reruns match on the workload and the source record, so scanning twice corrects the picture instead of doubling it.
In the current build -
2
Assessment
Score each asset for complexity, risk and target suitability, and derive the dependency graph the wave planner cuts against.
In the current build -
3
Reconciliation
Compare source and target estates and surface the matches, the collisions and the things that exist on one side only.
In the current build -
4
Treatment decisions
Rehost, refactor, replatform, rebuild, repurchase, retire, absorb or keep separate. Each decision is a record with an owner and a reason, not a cell in a spreadsheet, and an operator override freezes the row against a later re-run.
In the current build -
5
Business case
Turn the treatment set into cost and effort using rates the operator supplies. The arithmetic is the product's. The numbers are the engagement's.
In the current build -
6
Wave planning
Cut waves along dependency edges, geography and a complexity ceiling. Moving an asset out of a wave names the dependency that breaks.
In the current build -
7
Rehearsal
Start a wave and watch it run end to end without leaving the workspace: the jobs the wave would submit, the Microsoft or VMware primitive each one names, the outcome recording and the reversal package captured on success. No customer system is contacted.
In the current build -
8
Human approval
A cutover refuses to start until every asset in the wave carries a destination a person confirmed, every wave it waits on has completed and no hold is open on the plan. Binding an approval to a hash of the exact change set is designed and not built.
In the current build -
9
Execution
Run the approved plan through validated adapters. Execution today mints a synthetic job identifier and calls no customer system. Live adapters are planned and are not available.
Planned, not available -
10
Validation
Prove the target state matches the approved plan and that sign-in, mail flow and access work for the people in the wave. Depends on live execution.
Planned, not available -
11
Runoff
Hold redirects, forwarding and pause flags for a configurable window, thirty days by default, and clear them on schedule rather than on memory.
In the current build -
12
Closeout evidence
Every step lands in a hash-chained append-only ledger. Verification names the first row that fails to match, so a broken chain points at a record instead of at a feeling.
In the current build
Fifteen workload families, and what Simple Merge does with each one today.
This table is generated from the capability registry the product ships with. No status on it is typed by hand on this page, and a family cannot claim a stronger state than the evidence on its row supports.
- Rehearsal or simulated Modelled end to end in the operator workflow and rehearsed against synthetic data. The Microsoft or VMware primitive is named, and it is not called.
- Planned Designed, not built. No entry in the product capability registry and no adapter.
| Workload family | Underlying capability | Status today | What that means |
|---|---|---|---|
| Active Directory and Entra ID | Microsoft Graph user and group objects | Rehearsal or simulated | Directory objects are recreated, synchronised, converted or mapped in the target tenant. They do not move between tenants. On-premises Active Directory domain consolidation is planned and has no adapter. |
| Enterprise applications and app registrations | Microsoft Graph application and servicePrincipal re-registration | Rehearsal or simulated | Inventory, source-to-target match detection and the Create, Merge, Skip or Retire decision record are built. Re-registration in the target tenant is rehearsed against synthetic data. |
| SAML, OIDC, SCIM, permissions, claims, and consent | None yet | Planned | No entry in the product capability registry. The intended behaviour is described in the application and identity section on this page and is not built. |
| Exchange Online | Exchange Online Cross-Tenant Migration API and New-MigrationBatch | Rehearsal or simulated | Microsoft has made the cross-tenant mailbox move generally available. Simple Merge names it, plans against it and rehearses it. It does not call it today. |
| OneDrive | SharePoint Advanced Management cross-tenant user content move | Rehearsal or simulated | Microsoft schedules up to 4,000 OneDrive accounts in advance at a given time, which is a throughput ceiling the wave planner has to respect rather than one Simple Merge sets. |
| SharePoint | SharePoint Advanced Management cross-tenant site move | Rehearsal or simulated | Cross-tenant SharePoint site migration is a separate Microsoft path from the user data migration, and it is licensed separately. Planning treats it as its own track. |
| Supported Teams content | Microsoft Graph team and channel orchestration | Rehearsal or simulated | Microsoft's cross-tenant user data migration supports Teams chats and Teams meetings. Teams channels and shared data are out of scope by design and stay in the source tenant. That is a Microsoft product boundary, not a flag waiting to be switched on. |
| Intune, Autopilot, endpoint policies, applications, and assignments | Microsoft Graph device and Autopilot registration | Rehearsal or simulated | Devices and Autopilot profiles are modelled, against a documented ceiling of 350 Autopilot profiles per tenant. Policy, application and assignment migration is planned and is not in the capability registry. |
| Azure subscriptions and resources | Azure Resource Manager subscription tenant transfer | Rehearsal or simulated | Subscription transfer is the named primitive. Resource-level work is treatment decisions, dependency mapping and wave planning, not resource movement. |
| Windows and Linux servers | None yet | Planned | No entry in the product capability registry and no adapter. Assessment-pack scope only. |
| SQL Server and database targets | None yet | Planned | No entry in the product capability registry and no adapter. Assessment-pack scope only. |
| File shares and file-service destinations | None yet | Planned | No entry in the product capability registry and no adapter. Assessment-pack scope only. |
| VMware and Azure VMware Solution | VMware HCX | Rehearsal or simulated | One workload adapter among fifteen families. HCX Enterprise is bundled with Azure VMware Solution, which is why the plan can assume it rather than price it. |
| Security and governance controls | Microsoft Sentinel, Microsoft Purview and Microsoft Defender policy objects | Rehearsal or simulated | Workspaces and policy objects are inventoried and planned as first-class assets rather than as an afterthought at the end of a cutover. |
| DNS, domains, redirects, and mail routing | DNS zone and domain records | Rehearsal or simulated | Zones, redirect rules and the mail-routing runoff window are modelled. No registrar and no DNS provider is contacted by the product. |
What Microsoft itself does not carry across tenants
These are boundaries in the underlying platform, not gaps in a roadmap. A product that composes Microsoft capabilities cannot offer what Microsoft does not provide, and finding out on a cutover weekend is the expensive way to learn it.
- Teams channels and channel content
- Microsoft's cross-tenant user data migration does not migrate shared data such as Teams and channels. It stays in the source tenant. Simple Merge plans the manual or third-party treatment instead of implying a move.
- SharePoint sites inside the user data migration
- Site content is excluded from that path. Cross-tenant SharePoint migration is a separate Microsoft capability with its own licensing, and the plan treats it as a separate track.
- Identity movement of any kind
- The Microsoft path moves content, not identities. The customer is responsible for creating and configuring users in the target tenant, which is the work the identity sections of this page describe.
Every family above is at rehearsal or planned, and none is a production connector. Discovery populates a deterministic, obviously fictional inventory. Execution derives a synthetic job identifier and calls no customer system. When a live adapter lands, its row changes because the registry changed, not because this sentence was edited.
Tenant isolation, assigned-only visibility, and an evidence chain that names its first broken row.
Where the data lives
Simple Merge runs on Azure against a persistent Postgres store with pgvector. Every table is scoped by tenant identifier, and tenant scoping is composed into the query rather than left to whoever writes the next one. Deal data is a durable business record: a decision made in month two is evidence in month twenty.
Who can see what
Visibility is assigned-only by default. A non-admin member sees the plans they run or have decided on and nothing else in the workspace. Administrators see everything. The rule is enforced server-side in the query, not by hiding rows in the interface, and the same filter guards the MCP tools so an agent cannot reach what its caller could not.
The evidence chain
Each evidence row carries a hash computed over the previous row's hash and its own payload. Verification walks the chain and returns the position and identifier of the first row that fails to match, so a broken chain points at a record instead of at a suspicion. Decisions, executions, overrides, rollbacks and phase transitions all land in it.
Where the model sits, and where it does not
Asset matching is lexical and its rows say so: confidence is a token-level name similarity, not a model score. Treatment recommendations are flagged as recommendations and carry their reasoning, and today they come from a rule table rather than from a model. Where an agent acts at all, it acts through the same MCP tools the interface uses, and a tool that changes state writes its audit row inside the same transaction as the change. Reads are audited on a best-effort basis, so this is a record of MCP calls rather than a promise that none is ever missed.
Application and Identity Migration
Applications are where an integration stalls, because an application is not one object. It is a registration, a service principal, a claim set, a provisioning connector, an assignment list, a consent grant, and a vendor who has to be told. Four of the items below are in the current build. The rest are the designed behaviour of the application fold and say so on their own line.
Nothing on this list is available today. This is the product we intend to build, written down so you can tell us whether it is the right one, and it will change.
Inventory both sides
Enterprise applications are one of the workload classes discovery enumerates, on the acquired tenant and on the acquirer tenant, so the conversation starts from two lists rather than from a recollection.
Detect source-to-target matches
Every source application is scored against the acquirer applications of the same class on token-level name similarity, within the class only. An exact match after naming conventions are stripped scores one. Anything below the threshold, or with no counterpart left unclaimed, comes back as create-new with the reason written out. Matching is lexical, not semantic, and the page says so because the row does.
A person decides each one
The proposal is a proposal. An operator confirms or rejects it on the reconcile grid, and the decision is written with the person, the time, and the reason in the same transaction as the audit row and the evidence link. A rejection is recorded as an operator override rather than as a missing answer.
Then a treatment, and the treatment sticks
Rehost, refactor, replatform, rebuild, repurchase, retire, absorb or keep separate. Retire is a first-class outcome, because an acquisition is one of the few moments a duplicate application can actually be removed. Once an operator overrides a recommendation, a later re-run of the recommender leaves that row alone.
Additive differences only
Designed, not built. A merge decision would show the field-level difference and propose additions, preserving existing target configuration. Nothing already working on the target side is replaced to make the source side fit.
New client identifiers and credential replacement
Designed, not built. A recreated application gets a new client identifier and new credentials, tracked as work items with owners, because they are the change that silently breaks a running integration when nobody tells the vendor.
Claims, provisioning, assignments, permissions, and consent
Designed, not built. SAML claim mappings, SCIM provisioning, user and group assignments, delegated and application permissions, and admin consent would travel with the application rather than as separate tickets in a separate queue.
Vendor coordination on the wave
Designed, not built. Where a vendor has to update a redirect URI, an entity identifier, or a signing certificate, that dependency belongs on the wave with a date and an owner instead of in somebody's inbox.
Application objects do not move between tenants. No Microsoft primitive moves them, and Simple Merge does not claim one. An application is recreated in the target tenant, mapped to an application already there, merged into one through approved additive changes, or left in place.
Assessment Packs
Six planned packs, one engine that exists. A pack is a scoped entry point into the same asset inventory, dependency graph, treatment engine, business-case engine, wave planner, and evidence model, which is why a readiness assessment will be able to become an integration plan without being retyped. The engine is in the build. The packaging below is not a separate surface in the product today.
Active Directory and cloud identity readiness
Domain and tenant topology, duplicate and colliding accounts, group sprawl, synchronisation posture, and what has to be true on the target side before a single user is created there.
SQL, server, and file-estate Azure suitability
Which workloads are candidates for a managed Azure target, which are rehost, and which should be retired rather than moved. Assessment scope only: these families have no adapter.
VMware and Azure VMware Solution readiness
Cluster and capacity shape, network dependencies, and the sequencing an HCX-based move would need. One workload family out of fifteen, and priced into the plan as such.
Application and SSO migration
The application inventory, the source-to-target matches, and the treatment decisions described in the section above, scoped as a standalone piece of work.
Endpoint and Intune consolidation
Device estate, enrolment posture, Autopilot profiles against the documented per-tenant ceiling, and the policy and application assignments that have to be rebuilt rather than moved.
Microsoft 365 integration and separation
Mail, files, and supported collaboration content in both directions, because a carve-out is not an acquisition run backwards and the separation case has its own dependencies and its own runoff.
The packs will share one model rather than six. An asset discovered for the endpoint pack is the same row the identity pack reasons about, and a treatment decision made in one is visible in all of them. Server, database, and file-estate coverage is assessment scope only: those families have no entry in the capability registry and no adapter.
A cutover is refused, not warned about, until a person has decided the wave.
The gates below are the ones the product enforces on the single operation that would change an acquired company's estate. Each one refuses and says why, because by the time an operator reads a warning mid-cutover the link they needed is already torn down.
Every asset in the wave carries a confirmed destination
A wave holding an assignment still suggested, still in review, or rejected with no replacement target is refused, and the refusal names how many of each. Nobody has agreed where those assets land, so nothing moves.
Dependency order is enforced, not advised
The planner wrote which earlier waves this one waits on. A wave whose predecessors have not completed is refused by number, so the failure the dependency pass exists to prevent cannot be clicked past.
A hold is a hard stop
A pause flag against the plan, a workload class, or a named object blocks the wave that carries it. Holds are checked at the operation that changes the estate rather than rendered somewhere, because a hold that only renders is decoration.
Outcomes are recorded, never assumed
Submitting a job leaves it running until somebody reports what happened. Marking work succeeded at submission time produces an audit trail that says the migration worked when nobody has checked, which is the exact claim the evidence chain exists to make checkable.
A decision, once made, is not quietly rewritten
Re-running the matcher or the recommender skips rows an operator has already ruled on. A later pass can add to the picture; it cannot walk back a judgement and leave the plan looking as though nobody changed it.
The reversal package is captured at success, and the window is a gate
A succeeded execution captures its reversal payload in the same transaction that records the success, because reading that state at rollback time means reading a state the cutover has already changed. Once the runoff window closes the reversal is refused rather than half-performed.
Execution today derives a synthetic job identifier and calls no customer system, so the gates above govern a rehearsal rather than a live change. They are built, and they are what live execution will be gated by when it lands. Binding an approval to a hash of the exact change set, so that an altered plan invalidates the approval it already had, is designed and is not built.
How an integration runs
Planning is built. Execution is a rehearsal.
Eight steps from first inventory to closeout evidence. The planning half runs today against synthetic estates. The step that would touch a customer system does not touch one.
In sequence: Discovery and inventory (Simulated), then Assessment (Simulated), then Proposed plan (Simulated), then Operator review (Simulated), then Approval (Simulated), then Migration wave (Simulated), then Validation (Planned), then Evidence handoff (Simulated).
-
Discovery and inventory
SimulatedBuild the estate inventory for each workload in scope. Scanning twice corrects the picture rather than doubling it, because a re-run matches on the workload and the source record.
-
Assessment
SimulatedScore every asset for complexity, risk and target suitability, then compare the source and target estates and surface the matches, the collisions, and the things that exist on one side only.
-
Proposed plan
SimulatedEach asset gets a treatment with an owner and a reason, the treatment set turns into cost and effort at rates the operator supplies, and the waves are cut along dependency edges. Moving an asset out of a wave names the dependency that breaks.
-
Operator review
SimulatedStart a wave and watch it run end to end inside the workspace: the jobs it would submit, the Microsoft or VMware primitive each one names, the outcome recording, and the reversal package captured on success. No customer system is contacted.
-
Approval
SimulatedA cutover refuses to start until every asset in the wave carries a destination a person confirmed, every wave it waits on has completed, and no hold is open on the plan.
-
Migration wave
SimulatedThe approved plan runs. Today it mints a synthetic job identifier and calls no customer system, so what you are watching is a rehearsal of the wave rather than the wave.
Still planned Running this against live customer systems needs validated adapters, which are planned and are not available.
-
Validation
PlannedProve the target state matches the approved plan, and that sign-in, mail flow and access work for the people in the wave. This depends on live execution, so it is not something the rehearsal can stand in for.
-
Evidence handoff
SimulatedRedirects, forwarding and pause flags are held for a configurable window and cleared on schedule rather than on memory, and every step lands in a hash-chained append-only ledger. Verification names the first row that fails to match.
Simulated means the step is built and runs against synthetic data rather than against a customer estate. Planned means it is specified and not built. No step here is available, because the product is not reachable yet.
The human decision in this sequence
- What a person reviews
- An operator reads the wave: every asset in it, the destination confirmed for each one, the waves it waits on, and any hold left open on the plan.
- What gets approved
- That wave, with the destinations as they were confirmed. Approval is recorded against the wave rather than against the engagement.
- What approval makes possible
- A cutover can start. Until every asset carries a confirmed destination, every prerequisite wave has completed, and no hold is open, it refuses to start at all.
- What invalidates it
- A hold opened on the plan stops the cutover, and an asset whose destination changes is an asset without a confirmed destination again. Binding an approval to a hash of the exact change set is designed and is not built, so this page does not claim it.
- How failure is detected
- Each step records its own outcome, and closeout verification names the first ledger row that fails to match rather than reporting that something is wrong somewhere.
- Recovery and escalation
- A rehearsed wave captures a reversal package on success, which is what a rollback would use. Redirects, forwarding and pause flags are held for a configurable window and cleared on schedule. Escalation is to the operator who owns the plan, since an override freezes the affected row against a later re-run.
Everything above runs against synthetic estates today. Approval behaviour against a live customer system is unproven for the same reason execution is: no adapter contacts one.
Every claim above, and the file that backs it.
How ICM informs Simple Merge
Simple Merge decides what moves where in an acquisition or a carve-out, in what order, and who signs it off. The workflow below is the one the product runs today against a synthetic estate. No step in it contacts a customer system, and live execution is not built.
Planned. The steps marked built run today against synthetic data, not against a customer estate.
-
Context in
A plan, a source tenant, and a scan
An operator opens a merge plan against a named source estate, and a discovery scan enumerates the in-scope workload classes. Each asset is keyed on its workload together with the source record identifier, so a second scan corrects the picture rather than doubling it. Discovery today populates a deterministic, obviously fictional inventory instead of reading a real tenant.
Simulated
-
Retained or discarded
Estate shape is kept, estate contents are not
What the plan holds is what a plan needs: which assets exist, what class each one is, what it is called, where it sits, what depends on it, and what has been decided about it. Mailbox contents, files, messages, and directory attributes beyond the identity of the object are not read and not stored, because no adapter reads them.
Simulated
-
What the agent proposes
Matches, treatments, and waves, all as proposals
Each source asset is scored against target assets of the same class and comes back matched or as create-new with the reason written out; the scoring is token-level name similarity, not a model, and the rows record that. Each application also gets a treatment recommendation from the rehost, refactor, replatform, rebuild, repurchase, retire, absorb or keep-separate set, stored as a recommendation with its reasoning and derived today from a rule table rather than from a model. The planner then groups assets into waves under a complexity ceiling and records where a hard dependency forced a grouping it would otherwise have avoided.
Simulated
-
Human review a person decides
An operator confirms or rejects each assignment
The reconcile grid takes one decision per asset, written with the person, the time, and the reason. Rerunning the matcher or the recommender afterwards skips every row somebody has already ruled on, so a later pass can add to the picture and cannot walk back a judgement.
Simulated
-
Permitted effect
Today, nothing leaves the workspace
Starting a wave records what it would submit and which Microsoft or VMware capability each job would name, under a job identifier derived from the plan, wave, workload and attempt and prefixed to mark it synthetic. No Graph, Exchange, SharePoint, Azure Migrate or VMware HCX call is made. The production effect an approval would permit is designed and not built, which is why this step alone is marked designed.
Planned
-
Evidence recorded
A hash-chained ledger of the decisions and the runs
Decisions, operator overrides, execution outcomes, rollbacks and phase transitions are appended to an evidence ledger, each row hashed over the previous row's hash and its own payload. Verification walks the chain and returns the position and identifier of the first row that fails to match, so a broken chain points at a record rather than at a suspicion. The ledger covers those record types; it is not a log of every action in the product.
Simulated
-
Failure and refusal
A cutover refuses rather than warns
A wave holding an undecided assignment is refused and the refusal names how many. A wave whose predecessor waves have not completed is refused by number. A hold against the plan, a workload class, or a named object stops the wave carrying it. A succeeded run captures its reversal payload in the same transaction that records the success, and once the runoff window closes a reversal is refused rather than half-performed.
Simulated
These labels describe each step of this workflow on its own. They are not the availability of the product, which is the status shown at the top of this page.
This describes how the workflow is built. It is not a statement about availability, which is the status shown at the top of this page. ICM informs how context, review and evidence are designed here. It does not replace this product's database, its tenant isolation, its Entra identity, its audit tables, or its authorisation checks.
Methodology note
ICM was developed by Jake Van Clief and David McDermott. Simple Intelligence Group did not originate the methodology.
Simple Intelligence Group applies relevant ICM principles to context, provenance, traceability, human review, and workflow design.
Participation does not imply certification, endorsement, partnership, or an official ICM Architect designation.
The questions a buyer asks before trusting a migration plan.
Can I buy Simple Merge today?
No. It is not generally available, no price is published, and there is no purchase path on this site. What this page offers is product updates.
Is this a VMware migration product?
No. VMware and Azure VMware Solution is one workload family out of fifteen, at the same rehearsal state as the rest. Simple Merge is an M&A IT integration and carve-out execution control plane for Microsoft-centric estates.
Does it move identities between tenants?
No, and neither does Microsoft. The Microsoft cross-tenant user data migration moves content, not identities, and the customer remains responsible for creating and configuring users in the target tenant. Directory objects are recreated, synchronised, converted, or mapped. Simple Merge plans, sequences, and records that work.
What happens to Teams channels?
Teams channels and other shared data are outside the scope of the Microsoft cross-tenant user data migration and stay in the source tenant. Chats and meetings are inside it. That is a documented Microsoft product boundary rather than a feature waiting on a general-availability flag, so Simple Merge plans the manual or third-party treatment instead of implying a move.
What does "rehearsal" mean on the workload table?
The workload is modelled end to end in the operator workflow, the Microsoft or VMware capability that would carry it is named, and the plan is rehearsed against synthetic data. The product does not call that capability. Discovery generates a deterministic, obviously fictional inventory and execution derives a synthetic job identifier.
Who runs the actual integration?
Simple Intelligence Group builds the product. Organizations that need hands-on assessment, planning, and execution can engage Simplicity IT, a separate services company and Simple Merge delivery partner.
What does it cost?
Nothing is published. Pricing is not set, no plan is listed for sale, and any number quoted elsewhere is a draft that has not been approved.
The rest of the portfolio.
Simple Merge is the estate-change layer of SimpleOS, used when two estates have to become one or one has to become two. The plan it produces becomes delivery work in Simple Projects, the cutover raises its tickets in Simple Service, and every decision and execution it records is written to an evidence chain built to mirror into Simple Council.
Who does the work.
Organizations that need hands-on assessment, planning, and execution can engage Simplicity IT, a separate services company and Simple Merge delivery partner.
That is a services agreement with a different company on its own terms. It is not included with the product, and nothing on this page commits either company to a scope, a price, or a date.
Simple Merge is a product of Simple Intelligence Group. Simplicity IT Inc. is a separate legal entity and services partner.
Simple Merge is not open yet.
The operator workflow, the decision records, the waves, the gates in front of a cutover, and the evidence chain are built. The live adapters are not, and this page would rather say so than sell a cutover it cannot run. Tell us where to send word when execution lands.
Whichever you pick, a person reads it and replies. None of them approves access, starts a trial, or creates an account.