How midPoint can replace SAP IdM's SuccessFactors provisioning
If SAP IdM receives its employee records from SAP SuccessFactors, midPoint can take over that HR-driven joiner, mover and leaver processing before SAP IdM reaches end of mainstream maintenance in 2027. midPoint can read HR data through the community SuccessFactors connector or through a CSV or SCIM feed, then drive account creation, role assignment, changes and removals in the target systems. The main condition is that the feed must be proven before the source of truth moves. Until SuccessFactors is confirmed as the authoritative input to midPoint, SAP IdM should remain the system that provisions accounts. midPoint is open source with no license fee, and Evolveum offers optional subscriptions for support and feature work.
The proof is in the edge cases, not the happy path. Map the SuccessFactors fields that drive identity decisions, such as the worker identifier, the personnel and assignment records, effective dates, manager relationships, and the employment status codes that signal a leave, a rehire or a contractor. Confirm how the chosen feed handles future-dated terminations, reversed changes and records that arrive out of order. Then run midPoint's simulations against a copy of production data and compare every planned create, change and disable with what SAP IdM actually did over several weeks of real HR activity. Each unexplained difference is either a mapping defect or a process gap that must be closed first.
Plan the cost around people and operations rather than the software. Confirm with the connector documentation whether the SuccessFactors connector is supported, community or experimental, and test it on the exact SuccessFactors API version your tenant uses. Evolveum's Product Support subscriptions cover resolving product bugs under an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development. Its pricing is not published, so request a quote for each tier. Recurring costs will include servers, the PostgreSQL database, and the staff who maintain mappings after each HR configuration change. Any implementation partner should provide a written scope with deliverables and acceptance tests.
Which SAP IdM provisioning capabilities midPoint covers
This table maps the SAP IdM functions that handle identities arriving from SuccessFactors to the matching midPoint features and feed options. Read each row as a question to confirm in your own environment, because the SuccessFactors connector's field and event coverage must be checked against its documentation before you rely on it. The main takeaway is that midPoint covers the lifecycle and governance functions, but the HR-specific mapping work sits with your team and needs testing.
| SAP IdM function | midPoint equivalent | Feed or gap to confirm |
|---|---|---|
| HR inbound from SuccessFactors | Inbound mapping from the HR source into midPoint user objects through a resource and sync configuration | Community SuccessFactors connector, or a CSV or SCIM feed. Confirm which SuccessFactors entities and fields the connector reads |
| Joiner, mover and leaver events | Lifecycle handling driven by HR attribute changes, with provisioning and deprovisioning actions | Confirm how the connector surfaces effective-dated changes and rehires, which SAP IdM may have handled differently |
| Role assignment | Role-based access control with assignment rules driven by HR attributes such as organization or job code | Port the existing SAP IdM role model. Check how it maps to midPoint roles and whether any SAP-specific role logic needs rework |
| Target provisioning | Connector-based provisioning to target systems through ConnId, including LDAP, Active Directory, Microsoft Entra ID and SCIM2 targets | SAP R/3 and other SAP targets need their own connector check. Confirm connector status before planning the target scope |
| Approvals | Self-service access requests and approval workflows in midPoint | Approval paths from SAP IdM must be redesigned and tested. Confirm the workflow features you need in the release you plan to run |
| Audit and reporting | Auditing of changes and reporting on identity activity | Confirm that audit records meet your retention and evidence needs, and test them against your own reporting requests |
| Password reset | Self-service password reset in midPoint | Confirm how password synchronization works with each target system, since SAP IdM password flows may not carry over unchanged |
| SPML-specific behavior | Not a direct equivalent. midPoint uses its own provisioning model and connectors instead of SPML | Any SPML interface or custom SPML clients need replacing with connectors, SCIM or REST integration. Plan this work explicitly |
Choosing a SuccessFactors feed: connector, CSV or SCIM
midPoint can read SuccessFactors employee data through a community connector, a scheduled CSV export or a SCIM2 feed. Each option shifts work between SAP configuration, connector maintenance and error handling, so the choice should follow your SuccessFactors setup and who will own the feed after go-live.
Community SuccessFactors connector
A direct connector reads employee records from SuccessFactors and maps them into midPoint objects, which suits teams that want HR changes to flow without an intermediate file. Confirm the connector's status in the midPoint connector catalog before committing, because connector status ranges from supported to community and experimental. Ask who maintains the Java code, which SuccessFactors API version it targets, and how it handles paging, rate limits and deleted or rehired employees. Test those cases against a sandbox instance first.
Scheduled CSV export
A nightly or hourly CSV file produced from SuccessFactors and read by midPoint's CSV connector is the simplest feed to build and audit. Your HR or SAP team owns the export report, and midPoint's own tasks handle the import. The trade-off is change detection: a full file shows every employee each run, so midPoint must compare against the previous state, and a truncated or malformed file can look like mass leavers. Add row count and checksum checks before midPoint acts on the file.
SCIM2 feed
A SCIM2 endpoint exposes users as a standard REST resource, which fits organizations that already run a SCIM-capable middleware or identity hub between SuccessFactors and downstream systems. midPoint's SCIM2 connector is listed among the documented connectors, but the endpoint itself has to be provided, configured and secured by someone on your side. Confirm which SuccessFactors or middleware endpoints you can reach, how paging and filtering work, and how the feed reports errors per record so that a failed employee does not stop the whole batch.
Who builds and runs the feed
Each option divides ownership differently. A connector is Java code that someone must patch when SuccessFactors or midPoint changes, and an open-source community connector may come with no support commitment unless you buy one. A CSV feed moves the work to the HR reporting team. A SCIM endpoint sits in your integration layer. Decide before the pilot who gets alerts, who fixes mapping errors and who signs off on schema changes, and put those duties in the scope agreement.
SuccessFactors configuration to request
Whichever feed you choose, ask the SuccessFactors administrator for a stable employee identifier, effective-dated job and org data, and a way to see terminations and rehires. Connector use needs an API user with the right permissions and an agreed OAuth or basic-auth setup. CSV needs a saved report with fixed columns and a schedule. SCIM needs an endpoint and a token. Record the field list and effective-date rules in writing, because midPoint mappings depend on them.
Error handling and change detection
Trade-offs show up on bad days. A connector can fail on one record and report it through the task, a CSV batch can fail as a whole, and a SCIM feed can return per-item errors that midPoint must log and retry. Test a missing identifier, a duplicate employee, a late termination and a manager change. Require that every rejected record appears in a report that HR and the identity team review, and that no leaver is deprovisioned from an incomplete file.
How midPoint processes joiners, movers and leavers from HR data
midPoint treats the HR feed as the source of truth and builds each identity from it. In a typical setup, an HR-sourced resource (a CSV export, a SCIM feed or a SuccessFactors connector) is imported into midPoint, and an inbound mapping turns each employee record into a midPoint user object. Attributes such as the employee number, legal name, organizational unit, job code and employment status map to user properties, and a correlation rule decides whether a record matches an existing user. Before go-live, confirm which HR field is the stable key (the personnel number is the usual candidate), test the correlation against a copy of production data, and check how midPoint handles records that match nothing or match more than one user. Those cases should go to a review queue, not create duplicate accounts.
Movers are handled by recalculation, not by scripts that patch accounts. When an attribute that feeds a role assignment changes, such as department or job code, midPoint re-evaluates the assignments the user should hold, adds the roles that now apply and removes the ones that no longer do. Each role carries the account construction that ConnId connectors use to create or update the target account, so a move can change group membership in Active Directory or an entitlement in a target application without a separate workflow. Leavers follow the same path: when the HR status changes to terminated, the lifecycle state moves to disabled and the assignments are removed, which deprovisions target accounts on the schedule you configure. Test the delayed-leaver and rehire cases, because these determine whether access is removed too early or retained after a return.
ConnId only carries changes to target systems, and login stays with your identity provider. ConnId connectors are the Java components that speak each target's protocol, so midPoint's provisioning of Active Directory, Entra ID, LDAP or a SCIM application all pass through the same interface. midPoint is an identity management system, not an access management or SSO server, and does not act as the OAuth2, OpenID Connect or SAML server for your applications. Keep your existing identity provider for sign-in and let it consume the accounts midPoint provisions. Confirm with your identity team which directory the provider reads from, because a change in source of truth can alter which accounts users see at login.
Deployment choices for midPoint in your own infrastructure
A single Linux virtual machine is the simplest way to run midPoint inside your own data center or private cloud account. The application runs as a Java service on the VM, and the native repository database is PostgreSQL, which the Evolveum system requirements recommend running on a separate database server rather than on the same host. This model suits a first build for SuccessFactors joiner, mover and leaver processing, where you want to test connectors and mappings without introducing cluster complexity.
- Java runtime: midPoint 4.11 and later recommend Java 25 (Java 21 supported). midPoint 4.10 and older recommend Java 21 (Java 17 supported).
- Database placement: Put PostgreSQL on a dedicated server, sized and backed up independently of the midPoint host.
- Patching: You apply midPoint upgrades and OS patches yourself, so define a maintenance window and a rollback path.
- Single point of failure: One node means a host outage stops provisioning, so plan how HR-driven leavers are handled during an outage.
- Scale ceiling: A single node suits pilot and mid-sized populations, and capacity should be measured in your own environment before you commit.
Before you choose this model, confirm with Evolveum which midPoint release line matches your support window, because the Java requirement changes between 4.10 and 4.11.
midPoint can also run from Docker images, which fits teams that already operate container hosts and want reproducible builds across test and production. The image packages the application, but it does not remove the need for a PostgreSQL database, persistent storage for configuration and logs, and a deliberate image tagging policy. Container deployment changes how you patch and roll back, not what the application needs from its database.
- Image versioning: Pin the image to an exact midPoint release tag so that a rebuild does not silently change the version.
- External database: Keep PostgreSQL outside the container lifecycle, with its own backups and restore tests.
- Persistent volumes: Mount configuration, custom connectors and the home directory on persistent storage so restarts do not lose changes.
- Secrets handling: Pass database credentials and connector secrets through your secret store, not through image layers or plain environment files.
- Runtime Java version: The Java version follows the release you pin, so check the system requirements for that tag.
Before you adopt containers, confirm with your platform team how they handle image provenance and vulnerability scanning for the midPoint image in your own registry.
A multi-node deployment runs several midPoint nodes against one shared central database. The system requirements describe a sticky HTTP load balancer in front of the nodes, cache invalidation between nodes carried over HTTPS, and Quartz for distributed task scheduling so that scheduled reconciliation and synchronization tasks run once across the cluster. This model is for organizations that need the identity service to survive a node failure during joiner and leaver runs.
- Sticky load balancing: Session affinity keeps a user's web session on one node, which the load balancer configuration must preserve.
- Shared database: All nodes point at the same PostgreSQL repository, so database availability becomes the central dependency to design around.
- Cache invalidation: Nodes exchange cache invalidation messages over HTTPS, so certificates and network paths between nodes must be configured and monitored.
- Quartz scheduling: Confirm that scheduled HR synchronization tasks fire on one node only and that failover behavior matches your runbook.
- Operating effort: Load balancing, certificates, database high availability and cluster upgrades all add recurring work.
Before committing to a cluster, ask Evolveum or your implementer to walk through the cluster reference configuration for the exact release you plan to run.
What to test before midPoint becomes the source of truth
Write the acceptance criteria down before the first test runs, and get sign-off from HR operations, the identity team and the application owners who depend on the accounts. Each criterion should name the population, the expected result and the evidence that proves it. Cover at least these test categories: a parallel run in which midPoint computes the same joiner, mover and leaver outcomes that SAP IdM produces for the same SuccessFactors records; joiner and mover scenarios built from real HR edge cases, including rehires, concurrent changes in one record, leave of absence, and contractors who sit outside the standard employee feed; and termination timing, measured as the gap between the effective end date in SuccessFactors and the moment access is removed from each target system.
Test attribute mapping field by field. Confirm which SuccessFactors fields feed each midPoint attribute, how empty or changed values are handled, and which values are authoritative for the user object, the linked accounts and the assigned roles. Use midPoint simulations against a copy of production data to preview the changes a new mapping or role would make before anything is written to a target system, and review the affected population with the business owners. Check how the feed behaves when it is delayed, malformed or missing: midPoint should raise an alert, leave existing access unchanged, and recover cleanly once a complete feed arrives. Rehearse that failure path on purpose, because a silent stop is the most likely cause of wrong access. Keep SAP IdM running as the source of truth until every criterion passes, and confirm the exact connector version and feed format with Evolveum and your SuccessFactors administrators first.
Moving SuccessFactors provisioning from SAP IdM to midPoint
This sequence moves HR-driven joiner, mover and leaver processing from SAP IdM to midPoint in controlled stages, so that each population changes its source of truth only after the two systems have been shown to agree.
Inventory SAP IdM SuccessFactors jobs and mappings
The identity team, with the SAP IdM administrator, lists every job, sync rule, attribute mapping and derived value that reads from SuccessFactors and writes to downstream systems. Include the schedules, filters for excluded populations, handling of rehires and contractors, and any manual steps operators perform after a run. Capture the SuccessFactors fields and effective-dating rules each mapping depends on. The step is done when the team has a signed inventory that the HR systems owner has reviewed, and each row names the target system it feeds.
Choose the midPoint feed for SuccessFactors
Decide how midPoint will receive HR data: the community SuccessFactors connector, or an export feed in CSV or SCIM. Confirm with Evolveum's connector documentation and with HR which option is supported for your SuccessFactors configuration, and whether the connector status fits your support model. Agree who owns the feed, its schedule and its failure alerts. The step is done when the feed choice, its owner and the required SuccessFactors permissions are recorded in writing.
Build the midPoint feed in non-production
The midPoint engineer creates the HR resource, object templates and mappings in a non-production environment, using the inventory as the specification. Recreate the joiner, mover and leaver logic as lifecycle states and role assignments, and keep the existing SAP IdM business rules visible for comparison. Load a copy of the HR data and run simulations so that the expected changes can be read before anything is written to a target. The step is done when a test run produces the same account set and attributes as the inventory for a documented sample of employees.
Run both systems in parallel in observe mode
Configure midPoint against production SuccessFactors data in a mode that reads and computes changes without provisioning them, while SAP IdM stays the source of truth. Schedule the midPoint runs at the same cadence as the SAP IdM jobs so that comparisons are made on the same HR snapshot. Keep both systems' change logs and retain them for the review. The step is done when midPoint runs complete on the agreed schedule without connector errors and the operations team can read each proposed change.
Reconcile differences and fix the mappings
Compare the proposed midPoint changes with the actual SAP IdM outcomes for each population, such as employees, contractors, rehires, leavers and people on leave. Classify every difference as a midPoint defect, an SAP IdM defect, or an undocumented business rule that needs an owner decision. Fix the midPoint mappings, and record each decision with the approver. The step is done when the unexplained difference count is zero for the agreed test window and the HR and security owners have signed the reconciliation report.
Switch the source of truth one population at a time
Move one population at a time, starting with the smallest low-risk group, by disabling SAP IdM provisioning for that group and enabling midPoint to provision it. Keep rollback steps ready, including the SAP IdM job that can be re-enabled. Monitor the first full cycles for joiners, movers and leavers in that group before moving the next. The step is done when each switched population has completed at least one full cycle for every event type with no unplanned changes, and the change record names the approver for that population.
Decommission the SAP IdM SuccessFactors jobs
Once every population has been running on midPoint for the agreed stable period, disable the remaining SAP IdM SuccessFactors jobs, then archive their configuration, mappings and logs for audit retention. Remove the SAP IdM connections to SuccessFactors credentials that are no longer needed, and confirm that no downstream system still depends on SAP IdM output. The step is done when the audit team has the archive, the SuccessFactors service account reflects its new use, and the decommission record is signed.
Running midPoint alongside SAP IdM and the rest of the landscape
During a migration, SAP IdM and midPoint may both be active for the same people and systems. The four cards below cover the decisions that prevent conflicting writes, unclear attribute ownership, broken SAP-connected targets and gaps in audit evidence. Settle each one in writing before you move the SuccessFactors source of truth.
Duplicate account writes during parallel running
While both systems run, the same SuccessFactors joiner, mover or leaver event can reach SAP IdM and midPoint. If both write to one target, the final state depends on which write lands last. Assign one writer per target for each phase, and configure the other system as read-only or observer for that resource. Test a leaver on a non-production copy of the target before any live run. Confirm with your SAP IdM team how its jobs are scheduled and whether they can be paused without losing queued events.
Which system owns each attribute
Ownership is decided per attribute, not per system. For each target field, such as department, cost center, manager, job title and email, record which system is authoritative and which SuccessFactors field feeds it. Two systems mapping the same attribute show up as values that flip back and forth between runs. Build this table with HR and the target system owners before cutover, and treat one owner per attribute as a release gate. Confirm whether any attributes are edited by hand in target systems, because manual edits will be overwritten by whichever system runs next.
Keeping SAP-connected targets working
Targets in the SAP landscape may currently be served by connectors that SAP IdM provides. midPoint connects through the ConnId framework, and its connector catalog ranges from supported to community and experimental status. Check the status of any SAP-facing connector for your exact release before you rely on it, and test account creation, role assignment and deprovisioning against each SAP target. Where no tested connector exists, keep that target on SAP IdM or use an interim CSV or SCIM feed that you have verified end to end. Evolveum connector list
Audit evidence across both systems
An assessor will ask who changed an account, when, and under which request, and the answer may now sit in two logs. Keep a single register that records the cutover date for each target, the system that owned it in each period, and the change records exported from both platforms. Store exports under your records retention policy so that the trail stays complete after SAP IdM is decommissioned. Confirm with your auditors which evidence formats they accept and whether each system's logs capture the fields they need, such as the approver and the source event.
Questions buyers ask about replacing SuccessFactors provisioning
What does it cost to replace SuccessFactors provisioning with midPoint?
midPoint itself has no license fee, so the cost is the work and the infrastructure around it. The main components are servers or virtual machines for midPoint, a PostgreSQL database on its own server, the effort to build and test the SuccessFactors feed, and the staff time to run the platform afterwards. An optional Evolveum support or platform subscription adds a recurring fee that depends on the service level you choose. One-time costs cover analysis, connector work, role design, parallel running and cutover. Recurring costs cover hosting, database operations, patching and support. Ask any partner for a quote that separates these lines, names who performs each task, and states what is included in testing and handover.
How long does a SuccessFactors to midPoint migration take?
The timeline depends mainly on how many HR data rules you have, how many target systems depend on SAP IdM today, and how much of the joiner, mover and leaver logic must be rebuilt rather than copied. Other drivers are the form of the feed (a direct SuccessFactors connection, a CSV export or a SCIM feed), the number of approval and certification steps, and how long your test and change windows are. Each of these should appear as a separate phase in a written plan. Ask for a timeline that lists analysis, build, parallel run, source-of-truth switch and decommissioning as distinct milestones with exit criteria, and treat any single duration offered without that breakdown with caution.
Can our internal team replace SAP IdM provisioning without outside help?
A team with Java or scripting skills, directory administration experience and a clear understanding of HR data can do this, but the work is larger than a simple connector setup. midPoint uses its own object model for users, roles, resources and policies, and joiner, mover and leaver logic must be reproduced and tested against your real HR data. Teams often need help with role modeling, the SuccessFactors integration path, and the parallel run that proves the new system matches the old one. You can also use Evolveum support subscriptions or consulting for specific questions. Assess your team against these skills honestly, and confirm the platform knowledge you need with Evolveum before committing.
Is the community SuccessFactors connector ready for production use?
Whether it is production ready depends on your fields, your data volume and your target systems, so it cannot be answered in general. The connector status in the midPoint integration catalog ranges from supported to community and experimental, and you should confirm which status applies to the connector you plan to use. Test it against a copy of your SuccessFactors data that includes the edge cases you care about: rehires, concurrent employment, contractors, leave of absence, changes to manager and organization, and terminations with future dates. Check how it handles errors and retries. If the connector does not cover a field you need, a CSV or SCIM feed from an export may be a reasonable fallback, but it adds an extra process to operate.
What should we test before switching midPoint to be the source of truth?
Run midPoint in parallel with SAP IdM for a defined period and compare what each system would do with the same HR data. Key checks include: joiner accounts created with the correct attributes and roles, mover changes that remove old access and add new access, leaver processing that disables accounts on the right date, and exceptions such as rehires and contractors. Also test error handling, reprocessing after a failed run, and what happens when SuccessFactors is unavailable. Confirm audit logs record each change with enough detail for your reviewers. Only move the source of truth after the differences are explained and accepted in writing by the business owners.
What should we ask a partner for in a written scope?
A written scope should list the systems in scope, the HR data fields and events that drive joiners, movers and leavers, and the target systems that midPoint will provision. It should name the connectors to be used, with their status, and state whether any custom connector work is included. Ask for deliverables such as the configured midPoint environment, role and policy documentation, test plans and evidence, the parallel-run report, a cutover runbook, a rollback plan, and handover training. Clarify the testing approach, the named responsibilities on each side, and what happens if a connector does not meet the agreed requirements. Most DeployOpen engagements are fixed-scope, so the agreed scope, deliverables and timeline are set in writing before work starts, and a quote follows from that scope.
Who runs midPoint and the HR feed after the migration?
After cutover, your team or a support provider must operate midPoint, the database, the scheduled tasks and the HR feed. Operational work includes monitoring synchronization runs, handling failed records, applying midPoint releases, patching Java and PostgreSQL, and reviewing audit logs. Evolveum offers support subscriptions with different service levels, and DeployOpen offers ongoing support and upgrade retainers. Decide before the project starts who owns each operational task, how incidents are escalated, and how upgrades will be scheduled. Ask any partner to document the runbook and to define what is handed over and what remains with the vendor or with your staff.
What the work costs, and who is paid for what
The software license is the smallest line item. midPoint is open source under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states it has no enterprise edition, so there is no license fee to replace the SAP IdM license. The money goes to people and infrastructure: an integration partner or internal team to build the SuccessFactors connection, map HR attributes to midPoint objects and test joiner, mover and leaver scenarios; servers or virtual machines; and a PostgreSQL database that midPoint uses as its native repository, ideally on a separate database server. Evolveum sells Product Support subscriptions with 8x5 next-business-day or 24x7 SLA options and Platform Subscriptions that add feature development and roadmap influence. Those are optional, and the Evolveum support page lists no prices, so ask Evolveum for the tier and SLA that match your risk before budgeting for one.
Separate the one-time migration effort from the recurring run cost. One-time work includes the SuccessFactors connector build or customization (the community connector may need changes for your SuccessFactors configuration), HR data mapping and cleansing, the test cycles described above, parallel running against SAP IdM, and training for the team that will own the system. Recurring costs include infrastructure, database operations and backups, support subscriptions if you buy them, and staff time for upgrades. midPoint's release calendar matters here: 4.10 is supported until November 26, 2027, and 4.8 is a long-term support release supported until October 17, 2028, so plan upgrade effort against those dates as well as the Java version each release requires.
When requesting a quote, ask each bidder to price the connector work, the HR mapping, test support and cutover separately, and to state which assumptions depend on your SuccessFactors instance and sample data. Ask whether the price covers operating the platform after go-live or only building it, who carries the on-call duty, which midPoint release and Java version the design targets, and how upgrades, backups and connector maintenance are priced as a retainer. Ask Evolveum for the support tier, response times and what a Platform Subscription changes for a connector you depend on. Any quote that cannot itemize these items is not comparable with the others.
How DeployOpen scopes and delivers SuccessFactors provisioning work
DeployOpen plans, implements, integrates, tests and hands over self-hosted midPoint deployments inside the client's own infrastructure, including the HR-driven joiner, mover and leaver flows that SAP IdM currently handles for SuccessFactors. Engagements run against a written scope, so the source of truth, connector choice and cutover criteria are agreed before any production change.
How we scope
- We agree in writing which SuccessFactors data objects, employee events and target systems the migration covers.
- We confirm whether the community SuccessFactors connector, a CSV export or a SCIM feed is the intake path for your environment.
- We document the joiner, mover and leaver rules that SAP IdM applies today, so each one is mapped or retired on purpose.
How we build
- We deploy midPoint in your own infrastructure with PostgreSQL, sized against the Java and database requirements for your chosen release.
- We configure the HR intake, mapping, correlation and role assignment rules, then test them against non-production copies of employee data.
- We run simulations and reconciliation runs against representative data and record every mismatch against the SAP IdM output.
How we hand over
- We prepare a cutover plan with a parallel run period, rollback steps and named owners for each provisioning stage.
- We deliver configuration documentation, runbooks and test evidence so your team can operate and audit the joiner, mover and leaver flows.
- We agree the handover of the source of truth in writing, and we switch it only after the acceptance tests in the plan pass.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Support can cover midPoint release upgrades, connector changes when SuccessFactors configuration changes and periodic reconciliation reviews.
- Ask any quote to state which of these items are in scope, who operates the platform after go-live and which Evolveum subscription, if any, your team needs.
