What a midPoint implementation involves
A midPoint implementation is a project to build identity governance and administration inside your own infrastructure, and it costs money in four places: the implementation work, the hosting, any subscriptions you choose, and the internal people who run the system afterward. midPoint is an identity governance and administration platform written in Java and developed by Evolveum, and Evolveum states that it has no enterprise edition. Every line of code is published under open source licenses, so there is no license fee to compare against a commercial product. The budget therefore reflects what you pay to design, build and operate it.
Most projects start from one of three situations. The first is replacing a manual provisioning process, where access is granted and removed by tickets and spreadsheets. The second is audit pressure to show periodic access certification, meaning evidence that someone reviewed who has access to what and why. The third is joiner-mover-leaver automation, where a change in the HR record should drive account creation, role changes and removal across target systems. Confirm which of these drives your project, because the first design decisions, such as the authoritative HR source and the list of target systems, follow from it.
In-house or partner? For most teams, the sensible pattern is outside help for the first design and build, followed by internal operation. The deciding factor is the identity engineering skill you already have. If your team has built provisioning mappings, correlation rules and role models before, the split can move toward doing more yourselves. If not, the first build is where mistakes in role design and correlation become expensive to fix, so the first phase is usually where a partner adds the most value. Evolveum also sells support and platform subscriptions, which you can combine with partner work.
What the work includes and what you receive
Each block below is priced within a fixed scope agreed in writing before work starts. Admin training and connectors beyond the agreed target list are optional add-ons that appear as separate line items in the quote.
Discovery and requirements
Workshops with HR, application owners and the identity team record joiner, mover and leaver events, authoritative attributes, target systems in scope and audit obligations. The output is a signed requirements register and a list of open decisions. Check that every target system has a named owner and that the sign-off explicitly lists systems left out of scope.
HR authoritative source integration
This block designs the feed from the HR system that drives identity lifecycle, including which system owns employment status, how contractors and rehires are represented, and how conflicting updates are resolved. Ask the vendor to show the reconciliation rules and the test cases for leavers with pending access, since these decide how safe the lifecycle automation is.
Target system connectors
Each target is connected through ConnId-based connectors, such as LDAP, Active Directory, CSV, database tables, Microsoft Entra ID and SCIM, depending on what your estate runs. Confirm each connector's support status and version against current midPoint documentation before the quote is fixed. Connectors to systems outside the agreed list are optional add-ons.
Role model, approvals and certification
This block covers business and application roles, assignment policies, approval workflows and access certification campaigns that produce review evidence for auditors. Effort rises with the number of roles, approval paths and campaign scopes. Ask for the role catalog and the approver matrix to be agreed in writing before build starts, so that changes are priced as change requests.
Non-production and production environments
The work sets up a non-production environment that mirrors the production topology, then promotes configuration through a controlled path into a production deployment in your infrastructure. Testing covers lifecycle scenarios, connector behavior, approval paths and certification campaigns. Ask which test data sources are used and how production secrets are kept out of non-production.
Deliverables you keep
You receive the running deployment in your infrastructure, configuration as code or exported midPoint objects, a connector inventory, test evidence, runbooks for routine and recovery operations, and knowledge transfer to your administrators. Admin training sessions are an optional add-on. Confirm the repository ownership and export format in the contract so that you can operate the system without the implementation partner.
What drives cost and duration
This table lists the main drivers of midPoint project cost and duration, why each one moves the work, and how to keep it contained in a fixed-scope quote.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Identity sources and data quality | Each HR or directory feed needs its own mappings and correlation rules. Duplicate or inconsistent records add analysis and cleanup work. | Agree the authoritative source for each attribute early. Clean the feeds before build and name an owner for each data fix. |
| Target systems and connectors | Each target needs a connector, an account model and a test cycle. Targets without a supported connector need custom development. | Check connector status in the Evolveum catalog before scoping. Limit the first phase to a small set of targets. |
| Role model complexity | More business and application roles mean more assignment rules, exceptions and test cases. Role design needs repeated decisions from business owners. | Start with a short list of business roles. Add application roles only where a target system needs them. |
| Approvals, certification and evidence | Each approval path and certification campaign needs configuration, test cases and business sign-off. Auditors may also expect campaign records. | Standardize on a few approval patterns. Confirm evidence needs with the auditor before designing campaigns. |
| Custom schema and mappings | Schema extensions, object templates and custom expressions are built and tested by hand. Each one adds checks during upgrades. | Use standard attributes where they fit. Document each extension so upgrade tests can cover it. |
| Number of environments | Each environment needs its own configuration deployment, connector endpoints and test data. Production-like testing usually takes the most time. | Keep configuration in version control. Agree the number of environments and how changes are promoted between them. |
| High availability requirements | A multi-node setup adds a sticky load balancer, a shared PostgreSQL database, cache invalidation between nodes and distributed task scheduling. | Decide early whether multi-node operation is required. Plan database high availability and backups in the same design. |
| Release and Java choice | Release support dates and Java versions set the upgrade window and build pipeline. 4.8 LTS is supported until 17 October 2028. | Use a supported LTS release for production. Move to 4.11 on Java 25 only after connector and custom code tests pass. |
| Migration of existing accounts | Existing accounts must be correlated to identities before midPoint manages them. Mismatches usually need manual review. | Inventory accounts and their owners first. Run correlation in a test environment and agree how exceptions are handled. |
Project phases and what each produces
The sequence moves from a fit check and environment design to a tested pilot, a phased rollout by system, and a handover that leaves your team able to run midPoint.
Run discovery and fit check
The partner and your identity, HR and security owners inventory the HR source, target systems, existing account data and the access rules that must be kept. You receive a written findings summary and a go or no-go recommendation, with the scope and the duration for each phase tied to that scope. Ask each partner to state the duration in the quote rather than in a general estimate.
Design architecture and environment
The team chooses between a virtual machine and Docker images, places PostgreSQL on a separate database server, and decides whether a multi-node layout is needed. You receive an architecture document covering hosts, Java version (Java 21 for 4.10 and older, Java 25 for 4.11 and later), network paths, backups and the chosen midPoint release line, which should be confirmed against the Evolveum release and support dates before build starts.
Build HR source and first connector
The HR feed is mapped to midPoint users and lifecycle states, and the first target connector is built on the ConnId framework and tested in a non-production environment. You receive working joiner, mover and leaver flows for the first system, with test evidence showing that accounts are created, changed and disabled as the HR source dictates.
Design role model and approvals
Business and application roles are defined with owners, assignment policies and approval paths agreed with the people who sign off access. You receive a role catalog, a documented approval matrix and a list of the rules that remain manual, so that the design can be reviewed before it is built into midPoint.
Design access certification
Certification campaigns are designed for the populations, reviewers and frequencies your governance policy requires, with reminders and escalation rules. You receive a certification design document and a configured sample campaign that shows reviewers the access they must confirm and records each decision as audit evidence.
Test and pilot with a limited group
The configured flows run with a limited user group on real but controlled accounts, and defects are tracked and fixed before wider use. You receive a pilot report with test results, open defects and a sign-off decision from the system owners, which gates the rollout.
Roll out by system and hand over
Target systems are onboarded one at a time, each with its own cutover check, and the project closes with runbooks for operations, connector maintenance and upgrades. You receive a rollout record per system, the runbooks and a handover session, and you should confirm with the partner which support or retainer terms apply after close.
What stays in-house and what to outsource
This table compares each midPoint work package with who usually performs it, the skills it needs and where a partner adds the most value, so you can see which parts to keep and which to scope out.
| Work package | Who usually performs it | Skills required |
|---|---|---|
| HR data mapping and business owner decisions | In-house, with the HR system owner and business owners | HR system knowledge, data ownership decisions, familiarity with joiner, mover and leaver policy |
| midPoint architecture and installation | Partner-led on a first deployment, then transferred to in-house staff | Java runtime and application server administration, PostgreSQL administration, Linux, network and TLS design |
| Connector configuration for target systems | Shared, with partner building and in-house owners of each target system | ConnId connector configuration, directory administration (Active Directory, LDAP), application admin accounts and APIs |
| Role mining and role model design | Partner-led, with business input on who needs which access | Identity governance design, role engineering, analysis of existing entitlements, business process knowledge |
| Approval and certification design | Shared between the partner and internal audit or compliance | Identity governance design, audit evidence requirements, approval workflow configuration in midPoint |
| Testing and cutover | Shared, with in-house sign-off on each system before go-live | Test planning, midPoint object and mapping testing, change control, rollback planning, target system administration |
| Daily operations and upgrades | In-house, with optional Evolveum or partner support retainers | PostgreSQL backup and restore, Java version management, log and task monitoring, release note review |
What usually goes wrong and how to prevent it
Most midPoint delays and budget overruns trace back to a short list of decisions made too late or not at all. Each card names one failure point and the check that prevents it.
Unclear authoritative source
If no single system is agreed as the source of truth for joiners, movers and leavers, midPoint inherits conflicting attributes from HR, the directory and local admin tools. Before design starts, name the authoritative HR feed, agree which employee attributes it owns, and audit a sample of records for missing manager, department and employment status values. Poor HR data quality usually surfaces here, so budget time for cleanup with the HR data owners.
Roles designed before the access model
Teams often build a long catalog of business and application roles before agreeing who may request what, who approves it and which systems are in scope for each job family. The result is a role model that must be rebuilt after the first review cycle. Settle the access model with business owners and security first, then limit the first phase to a small set of roles tied to named systems.
Connectors deployed without a test target
Pointing a new ConnId connector at a production Active Directory, LDAP directory or SaaS tenant before a test target exists risks mass changes and locked accounts. Each connector needs a non-production target with representative data, a dry run of create, update and disable operations, and a rollback plan. Confirm with the target system owner that a test tenant or test domain is available before the quote is accepted.
Underestimated correlation of existing accounts
Existing accounts in target systems rarely match identities cleanly. Shared service accounts, renamed users, duplicate mailboxes and contractors with reused identifiers all need decisions on matching rules and manual review. Correlation is usually the largest unplanned effort in a first rollout. Ask for a correlation report on a sample of each target system before committing to a rollout schedule.
Approval flows without an owner
Approval workflows fail when nobody is accountable for approver lists, delegation during absence and escalation when an approver leaves. Requests then stall or are approved by default. Name a business owner for each approval path, document the fallback approver and the escalation timeout, and test a request end to end with the people who will actually approve it.
Certification campaigns auditors cannot trace
An access certification campaign produces evidence only if its scope, reviewers, decisions and remediation are recorded in a way an independent auditor can follow. Campaigns run without a documented scope, reviewer assignment rule or remediation log are hard to defend. Agree the campaign design, retention of decision records and the evidence an auditor will request before the first campaign runs. DeployOpen prepares controls and evidence, while the auditor forms the opinion.
Fixed-scope quote missing environments and cutover
A fixed-scope quote that covers only build work often omits the test, staging and production environments, data migration rehearsals and cutover support. Those items appear later as change requests. Ask that the written scope list each environment, the number of migration rehearsals, the target systems in each phase and the cutover support window, so the quote can be compared with your own estimate.
Release chosen without a support plan
Choosing a midPoint release on feature set alone can leave the platform without vendor bug fixes when the release leaves support. Compare the support end dates for the long-term support and feature releases, and check whether your internal team or a partner will carry upgrades before the end date. Include the Java version each release requires in the same decision, since the runtime change affects the host build.
How the project changes by starting point
With no existing identity manager to replace, the project starts from design. Scope centers on the HR source, the first target connectors and the role model, which usually take most of the effort.
- Discovery workshops: joiner, mover and leaver rules need agreed owners for each source and target.
- Role model design: business and application roles are designed before they are built, which adds design time.
- Version choice: confirm whether the long-term support line or a feature release fits, since support end dates differ.
- Quote should state: the number of sources and targets in scope and whether access certification is included.
Replacement adds an inventory of the current tool's provisioning logic and a period of parallel running, so the quote grows with how much logic must move. The detailed method is in the midPoint migration from legacy identity management topic.
- Rule inventory: existing provisioning rules, roles and exceptions are documented before any mapping is built.
- Account correlation: effort depends on how many accounts already exist in targets and how cleanly they match identities.
- Parallel running: both tools may operate side by side for a period, which adds environment and reconciliation work.
- Quote should state: which legacy systems are retired and who owns each cutover decision.
The platform choice shifts build and run work more than identity design. midPoint can run on a Linux virtual machine or from Docker images, and clustering details are covered in the midPoint high availability topic.
- Packaging: container images need a build and approval path, and the team must decide how configuration is supplied.
- Database placement: PostgreSQL is the native repository and is recommended on a separate database server, so decide where it runs.
- Operations skills: the run team needs cluster operations skills, which affects training and support scope.
- Quote should state: the deployment model, the image source and who maintains base images and the Java runtime.
Restricted networks add a mirroring step to every install and upgrade. The team must bring in the midPoint distribution, the Java runtime, PostgreSQL packages, container images and the connector sources the project uses, then keep them current.
- Artifact inventory: list every package, image and connector source before the build starts, including dependencies.
- Connector sources: confirm which connectors the target systems need and their status in the connector catalog, since some are community or experimental.
- Update cycle: each midPoint upgrade or connector change requires a new mirror cycle and approval.
- Quote should state: who builds the offline bundle, how its contents are verified and who approves transfers into the network.
What your team needs to provide
Before a fixed-scope quote for midPoint can be written, your team needs to supply a set of inputs. Each one changes the number of connectors, the amount of mapping work, the test effort or the timeline, so an incomplete list means a quote built on assumptions. The items below are the ones we need in writing, with a suggested owner for each.
Business owners and data access. Name a business owner for each identity source (typically the HR system) and each target system, such as Active Directory, LDAP, or a SaaS application. Owners decide which attributes are authoritative and which joiner, mover and leaver rules apply. Provide read access to sample HR and directory data so we can profile values, duplicates and correlation keys before design starts. HR operations and directory administrators usually own this.
Test accounts and non-production targets. Each connector needs a non-production target and dedicated test accounts with the rights midPoint will use. Without them, connector testing moves into production or slips, both of which add cost. The target system owner should confirm which operations the service account needs, such as create, update, disable and group membership changes, and document any API rate limits that affect synchronization design.
Infrastructure, release and approvals. Confirm the hosting model (virtual machines, Docker images, or a cluster you run), the separate PostgreSQL server, and the Java version your platform team will support. Evolveum recommends Java 21 for midPoint 4.10 and older and Java 25 for 4.11 and later, so the chosen release drives the runtime and upgrade plan. Also name the approval owners who will sign off on access requests and the certification reviewers who will attest to access. The identity lead and platform lead should own these decisions, with the CISO or compliance lead consulted on reviewer scope. A named security contact should own credentials, secrets and certificates used by connectors.
Acceptance process. Agree in advance who signs off each phase, what evidence counts as acceptance (test results, reconciliation reports, sample provisioning records) and how defects found after go-live are handled. Written acceptance criteria let the quote define deliverables precisely. The project sponsor should own this, with the identity team responsible for evidence.
Frequently asked questions about midPoint implementation cost
Is there a midPoint license fee I have to pay?
There is no paid enterprise edition of midPoint to buy, because Evolveum states that every line of midPoint code is published under open source licenses. Evolveum funds development through subscriptions, training and professional services. Its Product Support subscriptions cover resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions add feature development and roadmap influence. The support subscriptions page lists no prices, so request current subscription terms from Evolveum and compare them with the implementation, infrastructure and staffing costs in your quote.
How is a fixed-scope midPoint implementation quote built?
A fixed-scope quote is built from a written scope that lists the HR source, each target system and connector, the role model, the approval and certification processes, the rollout phases and the deliverables at handover. Each item is priced by the effort it needs, and the scope names what is excluded. The main cost drivers are the number of authoritative sources and target systems, the number of attributes that need mapping, the state of existing account data and the number of approval flows and certification campaigns. Ask for the assumptions behind each line, the client responsibilities and the change process if the scope moves.
How long does a midPoint project take to deliver?
Duration depends on the written scope, so DeployOpen does not give a timeline before one exists. The biggest factors are the number of systems to connect, the quality of HR and directory data, the complexity of the role model and the number of rollout phases. Ask for a phased plan with milestones, the dependencies on your staff and change windows, and the points where pilot results can change the scope. A duration given without these inputs has no basis yet.
Can our own team implement midPoint without an outside partner?
Yes, an internal team can implement midPoint if it has Java, PostgreSQL, directory and identity skills and enough time to learn the connector framework and object model. Evolveum offers training and professional services, and its public documentation covers installation and connectors. The decision usually depends on how many people can own the build, how quickly the system must go live and who will run it afterward. Ask a partner for a scoped estimate of your internal effort so you can compare it with a fixed-scope engagement that includes a handover plan.
What does midPoint need from our staff during implementation?
The project needs access and decisions from your staff, not only their time. Plan for an HR data owner who can confirm the authoritative source and lifecycle events, directory and application owners who can grant service accounts and test provisioning, and business owners who define roles, approvers and certifiers. A security reviewer should approve administrator authorizations and connector credentials. Name these people in the scope and agree response times, because delays in access or sign-off are a common cause of schedule slippage.
Which midPoint release should we choose, and how does Java affect effort?
Choose a release by its support window and your Java plan. According to the releases page, midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, 4.10 (Braille) is supported until 26 November 2027, and 4.9 support ends on 18 October 2026. Version 4.11 (Čapek) is planned for 21 October 2026. midPoint recommends Java 25 for 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. Moving to a different Java line adds runtime, build and test effort, so include it in the scope.
How DeployOpen scopes and delivers midPoint projects
DeployOpen plans and implements midPoint inside your own infrastructure, working from a written scope that sets out sources, connectors, role model, approvals and certification before any build starts. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Inventory the HR source, target systems and account types that midPoint must govern in the first phase.
- Agree in writing which connectors, such as ConnId LDAP, Active Directory or Entra ID, are in scope and how each is verified.
- Define the role model, approval paths and access certification campaigns that the written scope will deliver.
- Confirm the hosting target: VMs or Docker images, PostgreSQL placement, and the Java version your platform team supports.
How we build
- Set up a non-production midPoint environment with the agreed PostgreSQL repository and connector configuration.
- Build object templates, mappings and lifecycle rules from the HR source, then test them against sample identities.
- Run connector tests against non-production copies of each target system before any production synchronization is enabled.
- Document configuration decisions and test results so your team can review and reproduce each phase.
How we hand over
- Deliver configuration, connector settings, runbooks and test evidence against the acceptance criteria in the written scope.
- Walk your identity and operations staff through role assignments, certification campaigns and day-to-day administration.
- Hand over the phased rollout plan, with each system's cutover steps and rollback notes as agreed in scope.
- Confirm access to the repository, deployment code and documentation so your team can run midPoint without DeployOpen.
How we support
- Offer ongoing support, upgrades and testing as a retainer, with scope and response expectations agreed in writing.
- Plan midPoint upgrades against the release support dates on the Evolveum releases page before each change window.
- Coordinate with your Evolveum subscription choice, whether product support or a platform subscription, as your organization decides.
- Confirm with Evolveum and your own environment which subscription and support levels apply to your deployment.
