Before you plan a migration
Sinkrona Connect behaves like the MIM 2016 Synchronization Service unless we say otherwise. This page is where we say otherwise: what we left out on purpose, what is not in this version yet, and where we chose a safer behaviour. No small print – so you can plan your move without surprises.
Updated October 31, 2026, for the preview version 0.1.12.
Management agents, connector spaces, one metaverse, join and projection rules, precedence, provisioning and deprovisioning, run profiles, the Joiner and Preview work the way you know them. The names are the same, and so are the results. Your team's MIM knowledge carries over on day one.
These belong to MIM's past: things Microsoft itself deprecated, or things that tied the Synchronization Service to one Windows server and one way of working.
Connectors and rules extensions are recompiled against the Sinkrona SDK, which keeps the familiar ECMA2-style names and shapes. Porting is mostly mechanical.
Why: .NET Framework runs only on Windows and gets no new features. On .NET 10 your code runs on Windows and Linux, faster, and each extension is isolated with a time limit and a circuit breaker. Many extensions are no longer needed at all: built-in rules cover them.
One management agent per Active Directory domain or LDAP naming context, instead of several partitions in one agent. You still choose the containers to manage.
Why: each domain gets its own run profiles, schedule, credentials and history, and a problem in one domain no longer stops the others.
A browser portal you open from any PC, and a documented REST API that does everything the portal does – start runs, search, join, preview, set passwords, export configuration.
Why: no remote desktop to the sync server for daily work, and the same actions for people and scripts.
Sinkrona stores its data in MongoDB. The free Community Server is enough, on the same server or in your own cluster.
Why: identity objects with many, varying, multi-valued attributes are stored as they are and read in one go; it runs on Windows and Linux; and no database licence is needed.
Sinkrona Connect is the synchronization engine. Provisioning rules and reverse join replace what synchronization rules did. Requests, approvals and roles belong to Sinkrona Compass, a separate product.
Why: one product that does synchronization well, and one for governance – not one that does both halfway.
File-based ECMA2 interfaces, ECMA1/XMA and the legacy built-in management agents, join on "Any" object
type, "Do not recall attributes", TransactionProperties, and rules extensions in a separate
process.
Why: deprecated in MIM 2016 itself. Modern connectors and the isolation of every extension replace them.
Sinkrona Connect is in preview. These are not there yet. For each one there is a way to do the job now, and our pilot customers decide what comes first.
| In MIM Sync | In Sinkrona today | What you do instead |
|---|---|---|
| Password change notification from domain controllers (PCNS) | Not included. Sinkrona sets and changes passwords in every connected system through its API and portal. | During the migration, keep PCNS and MIM and let MIM hand passwords on to Sinkrona. We will build our own, end-to-end encrypted agent when customers need it – code inside every domain controller must be done carefully, not quickly. |
| Exchange mailbox provisioning in the AD management agent | The AD connector exports the mail attributes, but does not call Exchange. | A PowerShell management agent runs Enable-Mailbox or Enable-RemoteMailbox. |
| Oracle Database, LDIF, DSML and fixed-width files | Not included. Included: Active Directory, AD LDS, generic LDAP, Entra ID, SQL Server, MySQL/MariaDB, PostgreSQL, SCIM, REST, CSV, attribute-value-pair files and PowerShell. | The PowerShell connector reaches anything a script can; a direct LDAP connection usually replaces LDIF and DSML exports. |
| Delta import from the LDAP change log (389 DS, OpenDJ) | Full import in the generic LDAP connector (OpenLDAP has delta import). | Schedule full imports; Sinkrona only synchronizes what changed. |
| Reading a MIM server configuration export | Management agents are set up again in the portal. Sinkrona's own configuration export and import (one JSON file) is there. | Rebuild with us in the assessment. Built-in rules replace much of the old code, and it is a good moment to drop rules nobody uses any more. |
| Sign-in with Windows accounts | Sinkrona users with the same five roles as MIM's groups (Administrator, Operator, Joiner, Browse, PasswordSet). | One Sinkrona user per person and per script, with only the roles it needs. Users can already be linked to a Windows or Entra ID account. |
A warm standby server (miisactivate) |
No built-in switch-over. All state is in the database. | A second installation with the same key, its service stopped, started if the first server is lost; a MongoDB replica set keeps the data available. |
A few behaviours follow the MIM model with a safer result – one that never depends on the order of your rules and never leaves data half done:
And some things Sinkrona adds, all off until you turn them on: preview of any object, per-object delta synchronization, a built-in scheduler, reverse join, keeping group members it does not manage, automatic retries, Linux and containers, and HTTPS with your own certificate built in.
Tell us. This list is shaped by the people who run MIM Sync today, and our pilot customers decide what comes next. We go through your management agents, rules extensions and schedules with you and say plainly what moves as is, what needs a recompile, and what is worth simplifying.
