Business Apps 路 Coming Soon
Simple Merge

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.

Web Planned Copilot Planned
Request early access Volunteer to beta test Get product updates How it works

None of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.

Why this exists

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.

Readiness

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.

How it works

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
Workloads

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.

Workload families, the Microsoft or VMware capability behind each, and what Simple Merge does with it today.
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.

Architecture + security

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 every call lands in the audit log with the state change it caused in the same transaction.

Applications and identity

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

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.

Human control

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.

Evidence

Every claim above, and the file that backs it.

Execution calls no customer system.
In the build SimpleMerge lib/merge/execution.ts derives a sim- prefixed job identifier from the plan, wave, workload and attempt, and records by name the Microsoft or VMware primitive it would have called.
The evidence ledger is hash-chained and its breakage is locatable.
In the build SimpleMerge lib/merge/evidence.ts computes each row as sha256 over the previous hash and the payload; lib/merge/read.ts walks the chain and returns the index and row identifier of the first mismatch.
A cutover refuses to start while any asset in the wave is undecided.
In the build SimpleMerge lib/merge/execution.ts refuses a wave carrying assignments still in Suggested, InReview or Rejected, and names the counts in the refusal.
A re-run cannot quietly walk back a decision a person made.
In the build SimpleMerge lib/merge/assessment.ts and lib/merge/matching.ts both skip rows already in a decided status and count them toward the total the operator sees.
Tenant isolation and assigned-only visibility are enforced in the query, on both doors.
In the build SimpleMerge lib/visibility.ts supplies the filter that every read in lib/merge/ composes in, and the Server Action and the MCP tool call the same function with the same actor scope.
Every status word on this page comes from one registry.
In the build wordpress/theme/inc/merge-workloads.php mirrors SimpleMerge lib/merge/workload-registry.ts, and wordpress/theme/tests/simple-merge-test.php fails when the two lists drift apart.
Microsoft cross-tenant content migration does not carry Teams channels or SharePoint sites.
Published standard Microsoft's own documentation for cross-tenant user data migration, which scopes the feature to mailboxes, OneDrive, Teams chats and Teams meetings, and leaves shared data in the source tenant.
Storage posture
Persistent (Postgres + pgvector); evidence chain hash-bound
Certification target
None targeted yet
Distribution
Not listed for sale
Status
Coming Soon
Industries
Cross-Industry 路 Real Estate 路 Financial Services 路 Healthcare 路 Professional Services + IT 路 Private Markets
FAQ

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.

Methodology

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.

  1. 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.

    Built

  2. 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.

    Built

  3. 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.

    Built

  4. 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.

    Built

  5. 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.

    Designed

  6. 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.

    Built

  7. 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.

    Built

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.

How Simple Intelligence Group applies interpretable context

Where this sits

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.

Simple Council In Production 路 Controlled Early Access Run Agent 365 the way your regulator expects. Simple Projects In Production Project delivery that starts at the signed scope of work. Simple Service In Production ITSM on Microsoft 365, without the ConnectWise tax.
Delivery

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.

Request early access Volunteer to beta test Get product updates

Whichever you pick, a person reads it and replies. None of them approves access, starts a trial, or creates an account.