Choosing Apache Syncope over Microsoft Identity Manager for sync and password reset
If your Microsoft Identity Manager 2016 estate mainly synchronizes identities and runs self-service password reset, Apache Syncope is worth a close look before extended support ends in January 2029. Syncope covers the core of that job: it provisions identities to connected systems through the ConnId connector framework, ships an End-user UI for self-service and password reset, and exposes a REST interface built on Jakarta RESTful Web Services 3.1. Its Admin UI supports delegated administration, and Web Access handles SAML 2.0 and OpenID Connect single sign-on. Syncope is a strong fit when your workflows are few, your connectors are mainly Active Directory, SOAP, CSV or PowerShell targets, and your team is comfortable operating and extending a Java application.
Look at midPoint or another path if your requirements go beyond synchronization. Syncope is not a complete governance product, so confirm with the project and your own tests how it handles access request approvals, periodic certification campaigns and role mining, which many MIM customers use through the Portal and its workflows. Ask also how many multi-step approval paths you run today, and whether your certification obligations depend on evidence that must come from the tool itself. A heavy approval estate or a need for formal attestation usually points toward midPoint, which covers those areas directly.
The decision turns on four questions: how many workflows you must reproduce, whether reviews and certifications are in scope, which connectors your target systems need, and how much in-house Java and Maven capacity you can keep. Inventory each MIM management agent and Portal workflow against those questions before you pick a platform. Check the connector list for every target system, since a missing or custom connector moves effort into your team. Confirm the supported database engines for the release you plan to deploy, and test with the release you intend to run, starting from the Apache Syncope downloads page.
Which scenarios favor Apache Syncope
This table compares common Microsoft Identity Manager workloads with what Apache Syncope handles well and where a different route fits better. Read each row against your own connected systems, approval model and network constraints. The main takeaway is that Syncope suits identity-centric provisioning and self-service, while heavy governance needs usually point toward midPoint or Entra ID Governance.
| Scenario | Better fit | Condition and reason |
|---|---|---|
| Pure AD and HR-fed synchronization | Apache Syncope | Fits when HR is the authoritative source and you mainly create, update and disable accounts across a few targets through ConnId connectors, including Active Directory. Confirm the connectors you need exist for your systems. |
| Self-service password reset only | Apache Syncope | The End-user UI covers self-registration, self-service and password reset, so a PSPR-only need maps directly. Confirm how the reset flow integrates with your directory and MFA policy before committing. |
| Heavy Portal approval workflows | midPoint | Syncope has approval-style workflow features in its core, but multi-step request and approval flows built around MIM Portal are a closer match to midPoint's access request and approval model. Validate your approval chains in a proof of concept. |
| Access certification campaigns | midPoint | Certification campaigns are a governance function. Syncope is not designed around periodic reviewer attestation, so plan for midPoint certification or Entra ID access reviews if campaigns are a requirement. |
| Multi-forest or cross-cloud provisioning | midPoint | Complex multi-forest rules and mixed cloud targets with many attribute mappings are easier to model in midPoint's object templates. Entra ID Governance is the Microsoft route if cloud targets dominate. |
| Air-gapped or EU-controlled operation | Apache Syncope | Self-hosted deployment on your own infrastructure keeps identity data inside your network, with no required vendor cloud. Confirm the database and container images you need can be mirrored into the isolated environment. |
How Syncope's ConnId connectors compare with MIM management agents
Microsoft Identity Manager reaches each directory or database through a management agent, and custom logic lives in extensible rules. Apache Syncope reaches external systems through ConnId connectors that speak each target's protocol. The cards below show where those models differ in practice and what to confirm for your own target systems before you commit.
ConnId as the common connector layer
Syncope connects to external systems through the ConnId connector framework, the same framework midPoint uses. Each connector is a Java component behind a uniform interface that speaks the target's protocol. In MIM, each connected system has a management agent built for its type, such as Active Directory, SQL, LDAP or extensible connectivity. Ask which connector family each of your systems needs, because the connector model replaces the management agent model rather than mapping one to one.
Bundled connectors for common targets
The Syncope getting started guide names SOAP, CSV, PowerShell and Active Directory connectors. An Active Directory connector covers the directory that most MIM deployments synchronize with, so that part of the estate has a documented starting point. Confirm the connector version, supported directory features and whether your AD schema extensions are exposed. Treat the bundled list as a starting point, not a full inventory of what your environment needs.
Connectors you must write or maintain
A target system without a suitable connector needs a new one, which means Java development, testing against a non-production instance and version tracking for every upgrade of the target. In MIM, a custom management agent or extensible connectivity module carries the same burden. Ask for the connector inventory in writing, mark each system as available, adapted or custom, and assign an owner for each custom connector before the migration plan is set.
Where MIM rules extensions move
MIM rules extensions run custom code inside the synchronization pipeline, often to transform attributes or set values that the built-in rules cannot express. Syncope has no direct equivalent of this extension point, so logic is rebuilt as Syncope mappings, plug-in code or connector behavior. Inventory every rules extension and classify it as a mapping, a validation or a connector change. Expect this classification to drive most of the design work.
Testing connectors against production targets
A connector that works in a lab can still fail on your directory's OU layout, attribute constraints or service account permissions. Test each connector against a copy of the target with the same schema and permissions, including delete and disable operations. Confirm with the target system's owner which operations are permitted, since a faulty deprovisioning run can remove accounts that users still need.
Who supports each connector over time
A connector is code your organization or a partner must keep compatible with Syncope releases and with each target's updates. Apache Syncope is an open-source project under the Apache License 2.0, so no vendor is contractually obligated to maintain a connector for you. Ask any implementation partner who owns connector upgrades, how regression tests run and how a broken connector is handled between releases.
Apache Syncope vs Microsoft Identity Manager feature by feature
This table compares Apache Syncope's provisioning, connector, UI, API and licensing facts with the MIM 2016 capabilities you use today. Where a row shows a dash or a point to confirm, check that detail against Microsoft's documentation or a test in your own environment before deciding. The main takeaway is that Syncope covers identity synchronization and self-service well, but it is not a drop-in replacement for every MIM feature.
| Capability | Apache Syncope | Microsoft Identity Manager 2016 |
|---|---|---|
| Synchronization and provisioning | Synchronizes identity data across connected systems as its core identity management function | Synchronization Service moves identities between the metaverse and connected systems through management agents |
| Connector model | ConnId connector framework, with SOAP, CSV, PowerShell and Active Directory connectors listed | ECMA 2.0 management agents; confirm which connectors your sources require |
| Admin UI with delegated administration | Admin UI includes delegated administration | Portal provides administration; confirm delegated scopes against your current MIM setup |
| End-user UI for self-service and password reset | End-user UI covers self-registration, self-service and password reset | Self-service password reset through the MIM Portal and its dependencies; confirm the configuration you run |
| REST interface | Core exposes a Jakarta RESTful Web Services 3.1 interface | Confirm the Portal and Service APIs available to your integrations with Microsoft documentation |
| Web access and single sign-on | Syncope Web Access supports SAML 2.0 and OpenID Connect | Not a MIM feature; confirm which identity provider handles sign-in in your estate |
| Supported database platforms | PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later, Oracle Database 23 or later; Neo4j 5.26 or later is not stable for production | SQL Server backed; confirm supported versions against Microsoft documentation |
| License and release versions | Apache-2.0 license; 4.1.3 and 4.0.8 both released September 11, 2026 | Commercial Microsoft licensing; confirm support dates and license terms with Microsoft |
Where the Syncope end-user UI covers password reset and where MIM Portal workflows need rebuilding
Syncope's End-user UI covers self-registration, self-service and password reset, which is the part of the MIM Portal most sites use day to day. The Apache Syncope 4.1 getting started guide documents these functions in the End-user UI, alongside the Admin UI for delegated administration. Confirm the exact password reset flow you need against the guide for the 4.1.3 release, including how a user verifies identity (security questions, one-time codes or a token sent to a registered address) and whether the flow supports your password policy and lockout rules. Test it with a pilot group that mirrors your Active Directory password policy, because a reset that works in a lab can still fail on a domain-level policy you did not model. Confirm also how Web Access, the Syncope hub for authentication and single sign-on over SAML 2.0 and OpenID Connect, fits your sign-in path before you cut users over.
The Portal's request and approval workflows, custom forms and SharePoint-based pages do not carry over automatically. Each MIM Portal workflow, approval step, form field and SharePoint page is a configuration that has to be re-created, re-tested and owned by someone on your side. Start with an inventory: list every Portal workflow in use, the forms behind it, the approvers, and the SharePoint pages that link to it. For each item, decide whether to rebuild it in Syncope, keep it in another tool, or drop it because nobody uses it. Items that are only a request form with a manual approval usually map to Syncope's delegated administration. Items that depend on SharePoint or on approval chains with many conditions usually need a separate decision, because they may sit better in a workflow or governance tool. Record each decision with its owner and review date so the rebuild does not stall in the middle.
Who holds the identity data when Syncope runs in your infrastructure
Apache Syncope is self-hosted software, so the identity store, the connectors and the access gateways all sit where you deploy them. The cards below cover where that data lives, what the Web Access and SRA components change about your access surface, which database platforms the project names, and which audit evidence you must produce yourself.
Data location is your decision
Syncope stores identity data in its own internal database and synchronizes it to target systems through connectors. You choose whether that runs on-premises, in an air-gapped network or in your own cloud account. Nothing in the software requires a vendor-hosted tenant. Confirm with your architects where backups, logs and connector credentials are written, because those copies often leave the core system and are easy to overlook when comparing with MIM's on-premises footprint.
Hosting models you must choose
Syncope can be deployed as a set of Java services on your own servers, in containers, or in a cloud account you operate. DeployOpen plans and implements those deployments inside the client's infrastructure. Each model changes who patches the Java runtime, the database and the operating system. Ask for a written split of responsibilities before the design is approved, and record which party owns each upgrade.
Web Access and SRA widen the access surface
Web Access (WA) handles authentication, authorization and single sign-on through SAML 2.0 and OpenID Connect, so it becomes the place where sign-in policy lives. Secure Remote Access (SRA) is an API gateway with HTTP reverse proxying. Both are internet-facing candidates in many designs. Treat them as identity infrastructure: restrict exposure, review each proxied route, and test them as part of your security program.
Database platform support is specific
For internal storage, Apache Syncope 4.1.3 supports PostgreSQL 18 or later, MariaDB 12 or later, MySQL 9 or later and Oracle Database 23 or later. Neo4j 5.26 or later is functional but not considered stable for production. Check these minimums against your existing database standards before choosing a platform, since the MIM-era SQL Server dependency will not carry over.
Audit evidence you produce yourself
Syncope provides logs and administrative records, but you must decide how they are retained, who reviews them and how they reach your SIEM. Auditors will ask for evidence that account changes were authorized and traceable. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports or certifications. Independent auditors and certification bodies perform that assessment.
Connector credentials need custody
Each ConnId connector to Active Directory, PowerShell or CSV sources holds service credentials with rights in a target system. Those secrets must be stored, rotated and scoped deliberately, since they are the path to the connected directories. Document which account each connector uses and who can change its configuration, and confirm how your secrets manager integrates with the deployment.
Steps to move from Microsoft Identity Manager to Apache Syncope
This sequence moves MIM synchronization and Portal-driven provisioning to Apache Syncope one connected system at a time, with each step closed by a written check that the old and new flows agree. Confirm every step against your own environment before work starts.
Inventory management agents, rules extensions and Portal workflows
Start by listing every MIM management agent, its connected system, its run profiles, and each custom rules extension or script it depends on. Record which Portal workflows, request forms and approval steps trigger provisioning, and who owns each one. Confirm with the MIM administrators whether any agent reads from or writes to sources you have not documented. The step is done when you have a signed-off inventory that maps every connected system to its owner, its flows and its Portal dependencies, with gaps listed as open questions.
Map synchronization flows to Syncope schema
For each connected system, document the metaverse attribute flows and translate them into Syncope user and group schema, mappings and provisioning rules. Decide which attributes are authoritative in the source, which are derived, and how joins and matching rules will work, since Syncope's model differs from the MIM metaverse. Check the Syncope configuration against the Apache Syncope 4.1 getting started guide for the Core, Admin UI and End-user UI settings your version expects. The step closes when a reviewer can trace each MIM attribute flow to a named Syncope mapping, and each unmapped flow has a recorded decision.
Build and test ConnId connectors against non-production targets
Confirm which target systems have a ConnId connector already available for your Syncope version, and which need custom work or a SOAP, CSV, PowerShell or Active Directory connector. Build or configure each connector in a non-production environment and test create, update, disable and delete operations against a copy of the target. Include failure cases such as locked accounts and missing attributes, because MIM rules extensions often handle these in code that must be re-implemented. The step is complete when each connector passes the agreed test cases and the results are recorded for the cutover review.
Rebuild Portal workflows in the Syncope end-user and admin UIs
Recreate the self-service and delegated administration tasks that users and help desk staff currently perform in the MIM Portal, using the Syncope End-user UI for self-registration, self-service and password reset, and the Admin UI for delegated administration. Note any approval chain that Syncope does not cover out of the box and decide whether it moves to a separate workflow tool or is dropped. Confirm the password reset path with your security team, since it touches directory credentials. The step is done when each retained Portal task has a Syncope equivalent, a tester has completed it, and the gaps are logged as accepted or open risks.
Run MIM and Syncope in parallel for an agreed period
Run both systems against the same connected systems, with Syncope in read-only or dry-run mode where possible, and compare the resulting changes. Record every difference in account state, group membership and attribute values, then resolve each one by fixing the Syncope mapping or documenting why MIM behavior is intended. The length of the parallel period is a decision for the written scope, and you should agree it with the business owners before work starts. The step closes when the agreed period ends with differences either resolved or formally accepted.
Switch off MIM sync per connected system
Move each connected system to Syncope one at a time, starting with the lowest-risk system, and disable the corresponding MIM management agent run profiles once Syncope is confirmed as the writer. Keep the MIM configuration and database backups available for rollback during the cutover window. Verify after each switch that joiners, movers and leavers behave as expected, and that audit logs in Syncope capture the changes. The step is done when each connected system has a dated cutover record, a verified rollback path, and no remaining MIM agent writing to it.
Retire the MIM Portal and archive the configuration
Once every connected system is served by Syncope, remove user access to the MIM Portal, stop the MIM Synchronization Service, and archive the MIM databases, configuration and rules extension code under your retention policy. Confirm with your compliance owner which records must remain accessible and for how long, and document the archive location. Review remaining SharePoint or Windows Server dependencies that existed only for the Portal. The step is complete when the decommissioning checklist is signed off, the archive is verified and the MIM components are removed from production.
What Apache Syncope does not cover on its own
Apache Syncope handles provisioning, connectors, self-service and a REST API well, but governance controls sit outside its supplied capabilities. The cards below cover the governance needs that MIM shops often rely on today and that you must confirm or source elsewhere before a cutover.
Access certification and attestation
Periodic access reviews, where managers or application owners confirm that each entitlement is still needed, are the core of attestation. Many MIM shops use BHOLD or the Portal for this today, and the supplied Syncope facts do not establish a certification campaign engine. Ask the Syncope project directly, or check its documentation, whether reviews with reviewer assignment, escalation and evidence exports exist. If they do not, plan a separate tool or consider midPoint, which Evolveum describes as covering certification-adjacent features.
Segregation of duties rules
Segregation of duties (SoD) blocks combinations of entitlements, such as payment entry and payment approval, that one person should not hold. In a Syncope deployment these conflicts would have to be checked by custom logic in provisioning or by a separate policy engine. Confirm whether Syncope can evaluate conflicting entitlements at assignment time and report violations, and document how exceptions are approved and recorded.
Role mining and role design
Role mining analyzes existing access to propose roles, which matters when MIM-era group memberships have grown without a model. The supplied Syncope facts describe identity management and provisioning, not role mining analysis. Ask whether you can export current assignments and cluster them before you design roles. midPoint's role mining and simulations, as described by Evolveum, are the reference point to compare against.
Multi-step approval chains
Access requests often need approvals from a manager, a data owner and sometimes a security reviewer, with timeouts and delegation. Syncope's End-user UI covers self-registration, self-service and password reset, but the supplied facts do not describe configurable multi-level approval workflows. Map each current MIM Portal approval to a required step, then test whether Syncope can route it or whether you need midPoint's access request features.
Access request governance
Access request governance links a request to its justification, approval history and resulting provisioning, and keeps that trail for audit. This is more than a self-service screen. Before choosing Syncope, confirm how requests are logged, whether they are tied to the entitlement that results, and how they are reported. midPoint covers self-service access requests and auditing, so compare the audit output of both against your evidence needs.
How much effort does a move from Microsoft Identity Manager to Apache Syncope take?
What drives the cost of moving from Microsoft Identity Manager to Apache Syncope?
Cost is driven mostly by the number and complexity of connected systems, not by the Syncope license, which is free under the Apache License 2.0. The main cost components are the people doing the work: analysis of your existing management agents and rules extensions, building ConnId connectors or reusing existing ones, configuring Syncope mappings and workflows, testing in parallel with MIM, cutover, and documentation. Recurring costs include infrastructure for Syncope Core, Admin UI, End-user UI and the database, plus staff time for upgrades and connector maintenance. Ask any provider for a written breakdown by these components, with the assumptions behind each line.
How long does a migration from MIM to Syncope usually take?
The duration depends on how many connected systems you run, how much logic sits in MIM rules extensions and Portal workflows, and how many attribute flows must be reproduced exactly. Each connected system typically needs its own mapping, testing and cutover step, so a small directory-only estate moves far faster than one with HR feeds, custom approvals and many target systems. No duration figure is supplied here. Ask for a timeline in the written scope, with milestones for inventory, build, parallel run and retirement of each MIM sync run.
What skills does the team need to run a Syncope migration?
Your team should cover four areas: Java for reading and changing ConnId connectors and Syncope extensions, LDAP and Active Directory for the directory side, relational database administration for the PostgreSQL, MariaDB, MySQL or Oracle store that Syncope uses, and identity design for attribute mapping, provisioning rules and role logic. Someone must also own the REST API integration for any system that calls Syncope. If these skills are thin in-house, the gap is usually Java and connector work. Confirm which skills the proposal assigns to the vendor and which stay with your staff.
Can our own team migrate from MIM to Syncope without outside help?
Yes, if your team has the skills above and enough capacity to run MIM and Syncope in parallel for a period. Teams with a small number of connected systems, a clear inventory of MIM management agents and no complex Portal workflows are the most likely to succeed alone. The risks are in the unknowns: undocumented rules extensions, hidden attribute flows and cutover steps that interrupt joiner or leaver processes. A written assessment of your MIM estate, produced before committing to a build, is the cheapest way to decide between doing it in-house and hiring help.
What does a fixed-scope DeployOpen engagement cover for a Syncope migration?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Syncope migration, a fixed-scope engagement would typically cover the inventory of MIM agents and rules, the Syncope deployment and database setup, connector work, mapping and workflow configuration, parallel-run testing, cutover support and documentation. Scope, deliverables and timelines are agreed in writing before work starts. Ask for the list of connected systems, the exclusions and the acceptance criteria in the written scope.
Can Syncope replace the MIM Portal workflows?
Syncope covers part of what the MIM Portal does. Its Admin UI offers delegated administration, and its End-user UI handles self-registration, self-service and password reset, so the self-service and password reset parts of the Portal have a direct counterpart. Approval workflows, request forms and custom Portal logic usually need configuration or custom development, and some MIM Portal and SharePoint behavior has no direct equivalent. Ask any proposal to map each current Portal workflow to a Syncope feature, a custom build, or a retained process, and to state what is not covered.
How does licensing differ between MIM and Syncope?
Apache Syncope is licensed under Apache License 2.0, so there is no license fee for the software itself. Microsoft Identity Manager is a Microsoft product whose costs sit in the Windows Server, SQL Server and SharePoint dependencies, plus any Microsoft licensing needed for the extended support route. For Syncope, recurring costs are infrastructure, operations staff and any support or consulting contract you choose to buy from a third party. Confirm your current Microsoft licensing position with your Microsoft account team before comparing totals.
How DeployOpen helps evaluate, implement and migrate Apache Syncope
DeployOpen, a Chainscore Labs company, plans, implements, integrates, hardens and documents self-hosted open-source identity platforms inside the client's own infrastructure. For Microsoft Identity Manager shops weighing Apache Syncope, we start by testing the synchronization and self-service password reset flows you rely on today against what Syncope covers.
How we scope
- We inventory your MIM management agents, connected systems, Portal workflows and password reset dependencies before proposing any design.
- Each engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We identify which connectors need ConnId development or custom work, and which gaps need a documented decision or a different platform.
How we build
- We deploy Syncope Core, Admin UI, End-user UI and Web Access in your own cloud accounts, data centers or air-gapped networks.
- We configure the central repository database on a supported internal store and map identity flows to each target system.
- We run parallel synchronization against test directories and document the results before any production MIM sync run is switched off.
How we hand over
- We deliver architecture records, configuration documentation, runbooks and test evidence for your security and compliance teams.
- We provide knowledge transfer to your administrators on connector configuration, delegated administration and REST API use.
- We document what Syncope does not cover for your environment so governance, certification and reporting decisions are explicit.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow the Apache Syncope release line you select, and we test each release against your connectors before rollout.
- Security testing of the deployed platform, including applications and APIs, can be scoped as a separate engagement.
