Migrate from AD FS to WSO2 Identity Server

Migrate from AD FS to WSO2 Identity Server: what the work involves

The move from AD FS to WSO2 Identity Server is feasible for an estate with many WS-Federation relying parties, because WSO2 Identity Server supports WS-Federation alongside SAML, OpenID Connect and SCIM and can use Active Directory as a user store. The harder part is the relying party work, not the platform build: each trust has its own claim rules, endpoints, certificates and owners, and each one must be re-created, tested and cut over. Plan the project around the relying party inventory, and treat the identity platform as the smaller of the two workstreams. Identity engineers usually own the platform: the WSO2 Identity Server deployment on the chosen runtime, the JDK and database, the Active Directory user store connection, and the claim mappings that replace AD FS issuance transforms. Application owners must confirm each relying party's expected claims, signing certificate and logout behavior, and they must run user acceptance tests before any cutover. Security and compliance staff should review how the new service provider and claim configuration is documented and approved, since those records become the evidence for the change. The main risk is a relying party that depends on an AD FS behavior nobody wrote down, such as a specific claim rule, a token lifetime or a silent sign-in path. Run AD FS and WSO2 Identity Server in parallel for each application, route a small group of users first, and keep a rollback path to the AD FS trust until the owner signs off. Confirm with WSO2 which WS-Federation features your applications need before you commit to a design, and confirm which edition, open source build or subscription, covers the support you will require.

Which AD FS capabilities map to WSO2 Identity Server, and where the rework sits

This table maps the AD FS features your federation estate depends on to WSO2 Identity Server, with a status for each. Clean means the capability is supported and mostly configuration. Needs rework means the logic must be rebuilt, and gap means a separate component is likely needed. Confirm each claim transformation and publishing detail in the WSO2 documentation before scheduling relying party moves.

Capability	Status	What to confirm or rework
Relying party trusts	Needs rework	Each AD FS trust must be re-registered as a WSO2 service provider. Inventory every trust and its protocol first.
WS-Federation token issuance	Clean	WS-Federation is supported. Confirm token type, lifetime and audience settings for SharePoint-style apps in the WSO2 docs.
SAML token issuance	Clean	SAML 2.0 is supported. Re-create each SAML relying party with its metadata and confirm signing and encryption certificate handling.
Claim rules	Needs rework	Issuance and transformation rules must be rebuilt as WSO2 attribute mappings. Confirm claim transformation options in the WSO2 docs before writing any rule.
Active Directory authentication	Clean	Active Directory is a supported user store. Confirm bind account, search bases and group attributes with your directory team.
MFA policies	Needs rework	AD FS MFA providers and access policies must be re-created. Confirm which authenticators and conditional rules the WSO2 docs cover for your apps.
Web Application Proxy publishing	Gap	Confirm whether WSO2 Identity Server publishes internal apps. If it does not, plan a separate proxy such as Pomerium.

How the migration changes with estate size and starting point

A farm with a few dozen relying parties, most of them using WS-Federation, is the case WSO2 Identity Server is built to address, because it supports WS-Federation alongside SAML, OpenID Connect and SCIM. The work here is less about protocol translation and more about proving that each WS-Federation application receives the same token contents it received from AD FS. Inventory depth matters most in this situation, since claim rules often hide business logic that nobody has written down.

Inventory depth: Record the claim rules, token lifetimes, signing certificates and endpoint URLs for every relying party trust, not only the application names.
Wave count: Group relying parties by shared claim logic and by owner, then migrate low-risk apps first so the token mapping is proven before business-critical systems move.
Build or subscription: A proof-of-concept on the open source build is a reasonable way to test WS-Federation flows, but a production farm with many trusts should compare the unsupported GitHub build with a WSO2 subscription that includes expert support and vulnerability monitoring.
Parallel running: Keep AD FS answering for each application until its replacement passes sign-in and token tests.

Confirm with WSO2 which WS-Federation scenarios your applications use before you commit to a design.

What data and integrations move, and what you rebuild by hand

Most of an AD FS exit is inventory work. Users and groups stay where they are in Active Directory, and WSO2 Identity Server reads them through its Active Directory user store. Relying party trusts, claim rules, certificates and provisioning links do not carry over automatically, so each one needs an explicit decision and a rebuilt or retired counterpart.

Relying party trust inventory

Every AD FS relying party trust is a candidate for migration, but some are unused. Build the list from the AD FS configuration and its usage logs, recording protocol, endpoints, signing and encryption certificates, and the claim rules attached to each trust. Confirm the export method and the fields you can read in your own environment, because the exact steps depend on your AD FS version and admin tooling. Mark each trust as migrate, retire or replace with an entra-era or SaaS option before any WSO2 configuration starts.

User identities stay in Active Directory

Accounts, groups and attributes usually remain in Active Directory, so WSO2 Identity Server should read them through its Active Directory user store rather than copying them into a new database. Confirm which attributes each relying party needs, such as UPN, mail and group membership, and whether the service account has read access to the search base. Plan for the lookup load and for how disabled or locked accounts are treated at login.

WS-Federation endpoints to rebuild

WS-Federation relying parties, including SharePoint and other older Microsoft-integrated apps, point at the federation metadata and passive sign-in endpoints of AD FS. WSO2 Identity Server supports WS-Federation, so each application needs a matching service provider definition, its realm identifier and reply URL, and the claim mapping it expects. Test each one against a staging copy, since token shape and claim names are the usual breakage points.

SAML and OIDC clients to recreate

SAML and OpenID Connect applications are not converted from AD FS trust objects. Register each one in WSO2 Identity Server with its entity ID, assertion consumer URL, redirect URIs and client secret or certificate handling, then re-map claims to the attributes the app reads. Keep the signing certificate and metadata endpoints under change control, because applications that cache old metadata fail when the signing key rotates.

SCIM provisioning to reconfigure

Where an application receives user and group changes from AD FS-linked tooling or a separate provisioning job, that connection must be rebuilt against WSO2's SCIM endpoints. Confirm which apps create, update and deactivate accounts, and whether they expect SCIM 2.0 schemas or a custom payload. Decide who owns the provisioning schedule and how orphaned accounts are cleaned up during cutover.

Certificates, keys and cutover records

Token-signing and token-decrypting certificates, their expiry dates and the thumbprints that relying parties trust must be recorded before cutover. Each relying party needs its metadata updated or its trust re-established, and rollback depends on keeping the AD FS certificates valid until the last app moves. Keep a dated record of every change for your change advisory and audit evidence, and confirm the certificate lifetimes and rotation steps for your WSO2 build in the installation documentation.

The migration sequence from inventory to decommission

The sequence moves AD FS relying parties to WSO2 Identity Server in controlled waves, so each application is proven on the new issuer before users depend on it. Each step produces a record the next step relies on, ending with AD FS switched off only after a documented period of clean operation.

Build the relying party trust register
Export every relying party trust from AD FS with its protocol, endpoints, claim issuance rules, signing and encryption certificates, and token lifetimes. Pull the AD FS activity and usage data alongside it, so you can separate applications with live sign-ins from dormant trusts. The architecture team and the AD FS administrators own this work, and Microsoft's migration readiness tooling can support it. The step is done when the register has one row per trust, a named business owner, and a disposition of migrate, retire or keep for later.
Map WS-Federation claims and user store access
Translate each AD FS claim rule into a WSO2 Identity Server attribute mapping and confirm which Active Directory attributes feed each claim. Configure Active Directory as a user store, using a read-only service account, and check that group and UPN lookups return the same results as AD FS. Document any rule that depends on custom code or on AD FS-specific behavior, since those need design decisions rather than a direct copy. The step closes with a claim mapping sheet signed off by the application owners and a test directory query that matches AD FS output.
Stand up WSO2 Identity Server in a non-production environment
Deploy WSO2 Identity Server on the platform your team operates, whether Kubernetes, Docker, virtual machines or bare metal, using a supported production database rather than the embedded H2 database. Run it on a JDK that meets the version requirement in the installation documentation, and place it behind the same TLS and network controls your AD FS farm uses. Confirm the build choice at this point: the open source distribution is unsupported, while a subscription brings updates and expert support. The step is done when the non-production instance passes a health check and the backup of its configuration is tested.
Run a pilot relying party on WSO2
Choose one low-risk WS-Federation application with a small, known user group and re-create its trust on WSO2 Identity Server using the claim mapping from the previous step. Test sign-in in a browser, token contents, single sign-out where the application uses it, and the failure path when a user is not in the target group. Record every difference from the AD FS behavior, including token lifetimes and claim formats. The pilot is complete when the application owner signs off on the test results and the differences list has no open security findings.
Run AD FS and WSO2 in parallel by wave
Group the remaining relying parties into waves based on the register, starting with applications whose users can be moved in small numbers. Each wave is published on WSO2 Identity Server while AD FS continues to issue tokens for applications not yet moved, so users reach each application through one issuer at a time. Monitor sign-in success rates, failed authentication logs and help desk tickets on both platforms for each wave. A wave closes when its applications have run on WSO2 for an agreed observation period and the support team reports no unresolved issues.
Cut over each relying party with a rollback runbook
For each application, schedule a change window and switch the relying party's federation metadata and endpoints from AD FS to WSO2 Identity Server. Before the change, write a rollback runbook that states the exact metadata to restore, who authorizes the rollback, and the signal that triggers it. Keep the AD FS trust in place but disabled for the application until the rollback window passes. The cutover is done when the application signs in through WSO2 for all users and the rollback runbook has been reviewed by the change board.
Decommission AD FS after the last relying party moves
When the register shows no active trusts on AD FS, export the final configuration and logs for the record, then disable the trusts and stop the AD FS and Web Application Proxy services. Revoke the service accounts and certificates that only AD FS used, and remove the related DNS and load balancer entries once the rollback window has closed. Keep the archived export and logs under your retention policy, since auditors will look for evidence that federation moved and that old access paths were removed. The decommission is complete when the register is closed, the archive is stored, and the AD FS servers are removed from the monitoring inventory.

Deciding between the open source build and a WSO2 subscription

The licence on the code is not the decision that matters most. WSO2 Identity Server's source is licensed under Apache-2.0, and WSO2 publishes an unsupported open source distribution on GitHub that you can build and run yourself. What a WSO2 on-prem subscription adds is expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Before you commit to either path, confirm the current terms, including which distribution you may run in production, what the subscription covers for your deployment model, and how updates reach you, directly with WSO2 rather than relying on this page.

The practical question is who patches the platform and who answers a production incident. With the self-built distribution, your team tracks upstream releases, such as the v7.3.0 release published on May 13, 2026, rebuilds the image, tests it against your federation flows and rolls it out, and any defect you hit is yours to diagnose. For an estate with many WS-Federation relying parties, a failed token issuance can break sign-in for several applications at once, so the cost of a slow patch or an unanswered incident is high. Ask WSO2 what response commitments apply to each subscription tier and whether vulnerability notices are included.

Weigh the internal skills you actually have. Running the platform means managing the JDK requirement (Java 21 or Java 25), an external database, Active Directory as a user store, certificates for each relying party and the upgrade path. If your team lacks that depth, a subscription shifts some of the operational risk to the vendor, but it does not remove the need for your own runbooks. Put the subscription and any implementation partner fees into one written comparison with your internal staffing, so the decision reflects total effort and not only the licence line.

What drives the cost and duration of this migration

How does the number of relying parties and their protocols change the migration effort?

The count of relying parties and their protocol mix is usually the biggest driver of effort, because each trust is a separate piece of work. A SAML or OpenID Connect application is typically a configuration exercise, while a WS-Federation application such as an older SharePoint farm or a line-of-business app needs its own testing and sign-in validation. Keep effort down by sorting every trust into groups by protocol and owner before design starts, retiring trusts with no recent sign-ins, and moving the simplest group first so the team builds a repeatable pattern. Ask any implementation partner to price the work per trust group against your written inventory, not as a single lump sum.

Why do claim rules make an AD FS migration more expensive than expected?

Claim rules encode business logic such as which groups receive which claims, how names are transformed and which apps require specific attributes, and each rule must be reproduced and verified in WSO2 Identity Server's attribute and role mapping. Rules that were written years ago often contain undocumented conditions, so the translation requires reading each one and confirming intent with the application owner. Reduce this cost by exporting the trust settings first, deleting rules that no active application uses, and writing a short expected-claims table for each relying party that testers can check. Confirm with WSO2 which attribute mappings are needed for your specific WS-Federation and SAML apps before you estimate the work.

How do multiple Active Directory forests and domains affect the user store design?

Each Active Directory forest or domain you connect adds a user store to configure, a service account to manage, a search base to validate, and attribute differences to reconcile. WSO2 Identity Server supports Active Directory as a user store, but the number of directories determines how much identity matching, duplicate account handling and attribute normalization your team must design. Keep the cost down by confirming which forests hold active users, consolidating attributes such as userPrincipalName and mail into a single schema, and testing sign-in for trust-crossing accounts early. Ask your identity team to document every forest, trust direction and domain controller reachable from the WSO2 network segment.

Do MFA and conditional access rules add to the migration cost?

They do, because AD FS often enforces MFA through Azure MFA or third-party adapters, and conditional access logic tied to device, location or network may have no direct equivalent in WSO2 Identity Server. Each rule needs a target design, a fallback for users who lose access during cutover, and a security review sign-off. Costs fall when you list every MFA and access policy in writing, map each one to a WSO2 capability or to an external MFA service, and decide early which rules must stay in place for compliance. Confirm with WSO2 which authentication and adaptive policies your edition includes and which need custom work or a third-party tool.

How much testing effort do application owners add to the migration?

Testing often takes more effort than configuration because every application owner must confirm sign-in, role access, logout and session behavior after each relying party moves. The effort grows with the number of owners, the number of environments and the number of apps that have no test accounts. Keep it manageable by agreeing on a standard test script, creating test users in a non-production WSO2 environment, scheduling owner sign-off windows in advance, and grouping apps with the same owner into one test cycle. Ask for a written test plan with named owners before fixing a schedule, since untested apps are the most common source of late rework.

Does choosing the open source build or a WSO2 subscription change the total cost?

Yes. The open source build is licensed under Apache-2.0, so there is no license fee for the software itself, but WSO2 describes it as unsupported, so your team carries patching, vulnerability tracking and troubleshooting. A WSO2 on-prem subscription adds expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. The decision depends on your in-house skills, your tolerance for unsupported security fixes and your regulatory support expectations. Ask WSO2 for a written subscription quote that states the included support hours, response terms and update channel, and compare it with the internal staffing cost of running the open source build.

What operating and recurring costs follow the migration?

Once live, costs recur for the Java runtime, the database, hosting on Kubernetes, Docker, virtual machines or bare metal, certificates, backups, monitoring and upgrades. WSO2 Identity Server requires a JDK compliant with Java 21 or Java 25 and a production database such as PostgreSQL, MySQL, Oracle or Microsoft SQL Server, because the embedded H2 database is for development and testing only. Reduce ongoing cost by choosing a database and hosting model your team already operates, standardizing on the same release cadence across environments, and writing an upgrade runbook before go-live. Ask for the expected operating model in writing as part of the scope.

Can my own team run this migration without outside help?

Your team can run it alone if it already has experience with federation protocols, Active Directory administration, Java application servers and change control, and if it can commit the time for inventory, testing and cutover. Outside help is most useful for the tasks that are hardest to repeat, such as translating complex claim rules, designing the multi-forest user store, and planning the staged cutover. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and ongoing support and testing are available as retainers.

What usually goes wrong with WS-Federation relying party moves

WS-Federation moves tend to fail in the places where AD FS quietly did work for applications nobody documented. Each risk below has a preventive check built on inventory, claim testing and staged waves, so problems surface in a pilot wave rather than during cutover.

Undocumented relying parties after cutover

Legacy line-of-business apps, scheduled jobs and vendor tools often rely on AD FS trusts that no one lists in a current register. Build the inventory from the AD FS relying party trust configuration and from usage logs covering a full business cycle, such as month-end or payroll runs, not from the architecture diagram. Ask each application owner to confirm the endpoint, protocol and who signs off on their cutover before a wave is scheduled.

Claim mismatches breaking authorization

AD FS claim rules often emit values in a shape the application expects, such as a specific name identifier format, group claim type or UPN versus email. When WSO2 Identity Server maps the same Active Directory attributes differently, applications can sign users in yet deny access. Capture a sample token from AD FS for each relying party, then compare it field by field with the token WSO2 Identity Server issues for the same test account in a non-production tenant.

Signing certificate and key rotation errors

Relying parties hold a copy of the identity provider's signing certificate, and that copy must be replaced before the old one expires or is retired. Mistakes here cause sign-in failures that look like application bugs. Record every certificate thumbprint and expiry date from the AD FS trusts, plan a dual-certificate period where the application trusts both keys, and test metadata refresh on a single application before changing the rest.

Active Directory attribute gaps

WSO2 Identity Server can use Active Directory as a user store, but the attributes an application needs may not be mapped or may be empty for some users. Group membership used in AD FS rules, custom attributes and disabled or nested accounts are common gaps. Run a query against the user store for each claim the applications depend on, and report the count of users with missing values before the first wave.

Staged waves without a tested rollback

Moving all relying parties in one window removes the ability to isolate which application broke. Group them into waves by risk and dependency, starting with low-impact apps and keeping the AD FS trust active in parallel until each wave has run through a full cycle of use. Agree a rollback procedure for each wave, including who can re-enable the AD FS trust and how long that takes, and rehearse it before the cutover window opens.

Unclear ownership during the parallel period

While AD FS and WSO2 Identity Server both serve sign-ins, users may be sent to the wrong provider, and password or MFA changes may apply to only one of them. Name one owner for each relying party, define which provider is authoritative during each wave, and confirm with the application owners how sign-in failures are reported and routed to the team that can roll back.

Questions to settle before you commit to WSO2

Before signing anything, decide whether the open source build or a WSO2 subscription fits the estate. The public GitHub distribution is unsupported and suited to do-it-yourself builds, while commercial deployments receive updates for enhancements, fixes and performance plus expert support. Ask WSO2 in writing which distribution, support tier and update cadence apply to your environment, whether vulnerability monitoring is included, and what the subscription covers for commercial use. Ask DeployOpen for a written scope that names the WS-Federation relying parties in scope, the SAML, OpenID Connect and SCIM connectors you need, the Active Directory user store configuration, the target platform (Kubernetes, Docker, virtual machines or bare metal), and the database. Confirm that the database is one of the supported production engines, since the embedded H2 database is for development and testing only, and that the JDK version matches the supported Java release. Quotes should separate one-time work from recurring support and operations.

The internal team carries most of the risk, so define its inputs early. For each relying party, name a business owner who can approve the new trust, a technical owner who knows the claim rules and certificates, and a test account that resolves through Active Directory. Without these, WS-Federation applications such as SharePoint cannot be tested end to end before cutover. Ask the application owners which claims they actually read, since AD FS claim rules often carry more than the application uses. Agree who approves the Active Directory service account and read permissions that WSO2 will use, and who holds the certificates and signing keys. Plan a parallel run with a rollback path for each relying party, and confirm who signs off the test results. Settle these decisions in the written scope, because the vendor and the implementation team cannot set them for you.

How long does an AD FS to WSO2 migration take, and what does it cost?

How long does it take to move from AD FS to WSO2 Identity Server?

The timeline depends mostly on how many relying party trusts you have, how many of them use WS-Federation, and how clean your inventory is. A small estate with a handful of well-understood applications moves much faster than a farm with dozens of undocumented trusts, custom claim rules and applications nobody owns. Before any date is set, the inventory of relying parties, protocols, claims and real usage should be complete, because every unknown application adds testing and cutover work. A fixed-scope engagement sets the timeline in writing once that inventory is known. Ask for the timeline to be tied to named milestones rather than a single end date.

What drives the cost of an AD FS to WSO2 migration?

Cost follows the work, and the main drivers are:

The number of relying parties and how many use WS-Federation, SAML or OpenID Connect
The complexity of claim rules and how they map to WSO2 attribute mappings and claims
Active Directory integration as a user store, including attribute mapping and any LDAP service accounts
Testing for each application, including SharePoint or other WS-Federation apps and their sign-in flows
Infrastructure for WSO2 Identity Server, its database and high availability, plus the cutover plan
Documentation, runbooks and knowledge transfer to your operations team

Costs are one-time for migration and recurring for infrastructure, operations and any subscription. Ask any provider for a quote that breaks these items out separately.

Can our internal team migrate from AD FS to WSO2 without outside help?

Yes, a team with strong identity and Java operations experience can do it alone, and WSO2 Identity Server is available as an open source distribution on GitHub for self-built deployments. The open source distribution is unsupported, though, so your team carries all fixes, upgrades and vulnerability tracking. Teams usually struggle with the inventory of AD FS claim rules, the WS-Federation configuration for legacy applications and the cutover sequence, because these take time away from normal work. Confirm internally whether you have engineers available for a multi-month project, who will own the platform afterward, and whether you need expert support for production incidents.

Does WSO2 Identity Server require a paid subscription?

No. The WSO2 Identity Server source code is licensed under Apache-2.0, and WSO2 offers an unsupported open source distribution on GitHub that you can build and run yourself. A WSO2 on-prem subscription is optional and adds expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Confirm with WSO2 which distribution fits your use case and what the subscription terms include before you decide, because support and patch obligations differ between the two.

What does our organization need to provide for the migration?

The migration needs access and decisions more than large amounts of effort from you. Prepare:

An inventory of AD FS relying party trusts, claim rules and the owners of each application
Read access to the AD FS configuration and to the Active Directory domain that will serve as the user store
Test accounts and test environments for each relying party
Change windows for cutover and named business approvers for each application
Hosting for WSO2 Identity Server on Kubernetes, Docker, virtual machines or bare metal, with a supported JDK and a production database such as PostgreSQL, MySQL, Oracle or Microsoft SQL Server

The embedded H2 database is for development and testing only, so confirm early that production hosting is planned.

How does a fixed-scope DeployOpen engagement get agreed?

Most DeployOpen engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts. DeployOpen does not publish a price list. A quote follows from the written scope, which is why the relying party inventory is usually the first deliverable: it turns unknowns into a defined list of applications, protocols and cutover steps. The written scope should name what is in and out, such as which WS-Federation applications are covered, how Active Directory is connected, which environments are included and who signs off each cutover. Ongoing support, upgrades and testing are available as separate retainers.

What should we confirm about WS-Federation apps before agreeing a plan?

Confirm which applications actually depend on WS-Federation, because those drive most of the complexity. Ask whether each one needs token format or claim changes, whether it is still in use and whether its vendor supports SAML or OpenID Connect as an alternative. Applications that cannot change should be tested early, since they can determine the schedule. The answers should appear in the inventory and in the written scope, so the quote reflects real application risk rather than assumptions. Confirm these points with the application owners and, for WSO2 features, with WSO2 directly against its current documentation.

How DeployOpen scopes, runs and supports the migration

The sequence moves a WS-Federation and SAML estate from AD FS to a WSO2 Identity Server deployment that runs in your own infrastructure, with each relying party cut over under written scope and documented evidence. Engagements are fixed-scope, and ongoing support is available as a separate retainer.

Agree the written scope and deliverables
DeployOpen and your team agree in writing which relying parties, user stores, environments and cutover windows are in scope, along with the deliverables and acceptance criteria. Your identity, security and application owners sign off on the scope before any build work starts. The step is complete when the signed scope lists every deliverable and names who accepts each one.
Inventory relying parties and user stores
Working from the AD FS trust export and the relying party list, DeployOpen records each WS-Federation, SAML and OpenID Connect consumer, its claim rules, certificates and owner. It also confirms how Active Directory is used as a user store and which attributes each application depends on. The output is a register that marks each relying party as a direct WSO2 match, a re-platform task or a candidate for retirement, to be confirmed with the application owner.
Build the WSO2 platform in your environment
DeployOpen installs WSO2 Identity Server on the Kubernetes, Docker, virtual machine or bare metal platform you choose, with a JDK that meets the version requirements in WSO2's installation documentation and an external production database rather than the embedded H2 database. The team configures Active Directory as a user store and sets up the network path. The step closes when a test tenant authenticates a test user against the directory and the build is recorded in the runbook.
Re-create and translate relying party configurations
DeployOpen configures each WS-Federation, SAML and OIDC application in WSO2, maps the AD FS claim rules to WSO2 attribute mappings and tests the claims each application receives. Applications that WSO2 does not serve in the chosen configuration are flagged for a separate decision. The step is complete when each relying party passes functional tests in a non-production environment and the test results are filed against the register.
Harden and document the deployment
DeployOpen applies the hardening baseline agreed in scope, covering TLS, certificate lifecycle, administrative access, logging, backups and patch procedures, and writes the operating documentation. Where your assessors ask for it, the team prepares the configuration records and evidence that show how each control was implemented. DeployOpen prepares this evidence but does not issue audit reports or certifications, which remain with your independent auditor or certification body.
Run staged cutover and rollback checks
Relying parties move in the order set in the plan, usually starting with low-risk applications, with the AD FS trust kept available until each application is verified. DeployOpen documents the rollback step for each cutover and runs the checks with your application owners. Each cutover closes when the application signs in through WSO2 and the owner confirms in writing that access and claims are correct.
Hand over and retire AD FS trusts
After the final relying party is verified, DeployOpen runs a handover session, delivers the documentation and transfers administration to your team. AD FS trusts are removed only after the agreed observation period and the owners' sign-off. The handover is complete when the acceptance record is signed and the retired trusts are listed in the change log.
Continue support under a retainer
Upgrades, patches, monitoring reviews and new relying parties can be covered by a separate ongoing support retainer, scoped and priced in writing. Your team decides whether to use a WSO2 subscription for commercial updates and expert support, or to run the open source build without vendor support, and DeployOpen can support either path. The arrangement is in place when the retainer scope and responsibility matrix are signed.