How to export data from PingFederate before your contract changes
If your PingFederate renewal, licensing change or plan to leave is approaching, start by getting the configuration out in a form you control. The vendor documents a single archive export from the admin console, under System, Server, Configuration Archive, as a .zip file. That archive holds the complete admin console configuration, but it does not include launch scripts, web container configuration, logs, adapter and plugin drivers, the license file, cluster files or user-facing email and HTML templates. Plan to collect those items separately, and confirm the license terms with Ping before you rely on any of them.
This page covers what the archive contains and what it leaves out, why the archive is itself a sensitive asset, and how to turn connections, OAuth clients and certificates into a migration inventory for Keycloak. It also explains the version rule that matters at cutover: PingFederate will not import an archive from an older or newer version, so record the exact version that produced each export. Draft connections are not imported, so anything still in draft must be finished or recorded by hand.
The page describes only documented export paths. Where Ping's documentation is silent, such as how a specific adapter's settings are represented, the page tells you what to ask Ping or what to check in your own environment rather than assuming. Read the PingFederate configuration archive documentation alongside this page, and treat any archive as a secret with restricted access from the moment it is created.
What you can export from PingFederate and how
This table compares what a PingFederate configuration archive carries with what it leaves out, and what you must re-check by hand after import. Read the rows as a migration inventory: the archive is a starting point for connections, OAuth clients and certificates, not a complete copy of the deployment. The main takeaway is that the archive contains private keys, so it must be handled as a secret and matched to the exact source version.
| Exportable item | What the archive provides | Limits and what to check |
|---|---|---|
| Admin console configuration | Complete admin console configuration exported from System, Server, Configuration Archive as a .zip file | Imports only into a PingFederate version that matches the source; confirm the version before you start |
| Connections (SP and IdP) | SAML and OIDC connection settings held in the admin console configuration | Draft connections are not imported; publish or list each connection you need before exporting |
| OAuth clients | OAuth client definitions held in the admin console configuration | Record redirect URIs, client types and scopes separately so each one can be recreated in Keycloak |
| Certificates and key material | Certificates and private keys included in the archive | The archive contains private keys; store it as a secret, restrict access and never share it by email or chat |
| Adapter and plugin drivers | Not included in the archive | Copy the drivers from the server installation and map each adapter to a Keycloak flow or mapper by hand |
| License file and cluster files | Not included in the archive | Keep the license file and cluster files under your own records; they do not carry over to Keycloak |
| Email and HTML templates | Not included in the archive | Copy user-facing templates from the server and rebuild them in Keycloak themes |
| Admin console content to re-check after import | Connection, client and certificate settings restored from the archive | Re-check endpoints, attribute contracts, signing and encryption settings, and expiry dates by hand before cutover |
What the PingFederate archive leaves out and how to recover it
A PingFederate configuration archive is a starting point, not a full backup of the server. Several components sit outside the .zip, so the migration inventory has to be assembled from those components, your own copies and the vendor's documentation.
Launch scripts
Startup and shutdown scripts that start the PingFederate process are not in the archive. Teams that tuned Java options, file descriptor limits or service wrappers for their environment must copy those settings from the running server. Check the install directory on each node and record any custom changes so the Keycloak runtime can reproduce the same behavior.
Web container configuration
The archive omits the web container settings that expose PingFederate, including the listener ports, TLS bindings and proxy or header rules. These details drive how users reach the federation endpoints, so they matter for redirect URIs and cookie behavior. Export them from the container configuration on each server and list every public hostname that clients use today.
Logs
Runtime and audit logs are not part of the configuration archive. They hold the record of which relying parties authenticated, which connections failed and when certificates were rejected. Keep an archived copy under your retention policy before decommissioning, because logs are often the only evidence of how a connection behaved in production.
Adapter and plugin drivers
Adapter and plugin driver files are excluded from the archive, yet connections often depend on them. Custom authentication adapters and their JAR files must be found in your own repositories or the vendor's distribution, then reviewed for the logic they perform. Each one maps to a Keycloak authenticator, user federation provider or custom SPI, so confirm with Ping which versions your drivers target.
License file
The license file is excluded from the archive and must be retrieved from Ping's customer portal or your procurement records. It determines entitlements such as connection counts and features that the old deployment used. Keep it for the contract record and for the cost comparison, and confirm with Ping how license terms apply during a transition period.
Cluster files and email templates
Cluster files that define node membership and replication are not in the archive, and neither are user-facing email and HTML templates for password reset or consent screens. Templates must be copied from the server and rebuilt as Keycloak theme and email settings. Inventory both from the running environment, then test every user-visible page on a staging Keycloak realm before cutover.
Why the archive contains private keys and how to handle it
A PingFederate configuration archive contains private keys, which is why Ping warns that sharing it is a security risk. Treat the .zip from System, Server, Configuration Archive as a secret in its own right, not as a settings file. Anyone who obtains it may be able to recover the signing and token-encryption keys that protect your SAML and OAuth trust relationships, so the archive needs the same handling you would give a certificate store export. Before anyone downloads it, confirm with your own security team which key material the archive holds, since the vendor documentation establishes the risk but your certificate inventory determines the exposure.
Set handling rules before the export runs, not after. Name a small set of custodians, typically two people from identity engineering with a backup from security, and make them the only people who can download, move or open the file. Store it only in a restricted location with access logging, and confirm that the storage is encrypted at rest under keys your organization controls. Keep the file out of ticketing systems, chat, shared drives and developer laptops. Record every hand-off in a simple log that states who held the file, when, where it was stored and why, because that record is what an auditor or incident responder will ask for first.
Plan the end of the archive's life as carefully as its creation. Once the Keycloak import has been verified and the new signing keys are in place, delete the archive from every location where it was stored, including backups and copies made during troubleshooting, and record the deletion in the same log. Do not reuse the old keys in the new platform simply because the import succeeded, because the keys were exposed to everyone who handled the archive. Rotate them, update the relying parties that trust them, and confirm with the application owners that the change is complete before you retire PingFederate.
The export sequence, from draft cleanup to a verified archive
This sequence turns a PingFederate installation into a single, checked configuration archive and a written inventory of everything the archive leaves out, so the Keycloak migration starts from known facts rather than memory.
Confirm the PingFederate version and archive source
Record the exact PingFederate version running in production, including any cluster nodes, and confirm that the archive will be taken from that same version. PingFederate does not import an archive from an older or newer version, so a version mismatch will block the restore later. Ask the Ping administrator to write the version into the migration ticket. The step is done when the version, the admin console host and the owner of the export are recorded in one place.
Finish or remove draft connections
Open the connection lists in the admin console and look for drafts, meaning connections saved but not yet activated. Draft connections are not included in the archive, so each one either needs to be completed and saved, or deliberately deleted with the owning application team's agreement. Record every draft by name in the inventory so none disappears silently. The step is complete when the list of drafts is empty or every remaining draft has a written decision.
Export the archive from the admin console
In the admin console, go to System, Server, Configuration Archive and generate the archive, which downloads as a .zip file. Run the export from a workstation you control, not a shared desktop, because the file contains private keys. Keep the export time and the administrator's name in the change record. The step is done when a single .zip file exists with a clear name that includes the environment and date.
Record the file hash and storage location
Calculate a SHA-256 hash of the archive with a standard tool such as
sha256sumon Linux orGet-FileHashin PowerShell, and write the hash, file name, size and storage path into the migration inventory. Recalculate the hash before any restore or copy to confirm the file has not changed. The step is verified when a second hash calculation produces the same value.Collect the items the archive excludes
Gather separately the items the archive does not hold: adapter and plugin drivers, the license file, launch scripts, web container configuration, cluster files, and user-facing email and HTML templates. Copy them from the server file system under change control, and list each item with its location and owner. Identify which adapters the connections depend on, because the new platform will need equivalent logic. The step is verified when every excluded item has a row in the inventory with a source path or a note that it no longer exists.
Build the migration inventory from the archive
Using the archive contents and the admin console, list each SAML and OIDC connection, OAuth client, signing and decryption certificate, and data store. For each row, record the protocol, the relying party, the attributes sent and the owner. Then compare the count of connections and OAuth clients in the inventory against the counts shown in the admin console. The step is complete when the two counts match, and any gap is explained in writing.
Store the archive under the security rules
Move the archive into an encrypted location with access limited to named migration staff, and do not attach it to tickets, chat or email. Log every access and make the copy count explicit, so the team knows where every copy lives. Plan its deletion once the Keycloak migration is accepted, and record that decision. The step is verified when the access list is written down and a test user without access cannot open the file.
Turning connections, OAuth clients and certificates into a migration inventory
A PingFederate archive gives you the raw configuration, but a migration needs a structured inventory that maps each item to a Keycloak concept. The six cards below cover the items to record, the Keycloak target for each, and the questions to settle with application owners before any import work starts.
SAML and OIDC connections
Record every SAML service provider and OIDC client connection, its protocol, entity ID or client ID, redirect URIs and whether it is active or only in draft. Draft connections are not imported from the archive, so list them separately from the admin console. In Keycloak, active SAML connections map to SAML clients and OIDC connections map to OpenID Connect clients within a realm. Confirm with each application owner which endpoints are still in use.
OAuth clients and grant settings
For each OAuth client, record the client type, allowed grant types, scopes, PKCE requirement and token endpoint authentication method. These settings decide whether a Keycloak client is confidential or public and which flows stay enabled. Keycloak clients carry equivalent switches, so a grant that was allowed by accident in PingFederate should be caught here rather than copied. Ask owners whether any client relies on the implicit flow or resource owner password grant before mapping it.
Signing and decryption certificates
List each signing and decryption key pair with its subject, issuer, serial number and expiry date. The archive contains private keys, so store this inventory in a controlled location and treat the archive file itself as sensitive. In Keycloak, signing keys belong to the realm key configuration, and relying parties need the new public certificate before cutover. Record which relying parties trust each certificate, since a rotation without that list breaks sign-in.
Attribute contracts and data stores
Record which attributes each connection sends, including source, name and format, and which user store supplies them. Attribute contracts become protocol mappers in Keycloak, and attributes pulled from a directory become user federation settings. Note any transformation applied in PingFederate, because each one needs an equivalent mapper or it is lost. Confirm with owners that the attribute names expected by their applications have not changed.
Token and session settings
Record access token and refresh token lifetimes, session timeouts, idle limits and any single logout behavior for each connection. Keycloak sets these at realm and client level, so differences between applications must be kept as client overrides. Confirm with owners how long their users stay signed in and whether they depend on specific claims or lifetimes. Changing these values during migration can cause unexpected sign-outs or session extensions.
Adapter and plugin dependencies
Record each adapter, integration kit or plugin that a connection uses, since the archive does not include adapter and plugin drivers. Keycloak does not run PingFederate adapters, so each one must be replaced by a Keycloak authenticator, a broker or an application-side change. Keep a list of what must be obtained again from the vendor or rebuilt, and confirm with the application owner which integration code they will maintain after cutover.
What Keycloak can take from the inventory and what it cannot
The PingFederate inventory does not import into Keycloak. Keycloak exports and imports realms as JSON files with the kc.sh export and kc.sh import commands, but those files describe Keycloak realms, clients, roles and users, not PingFederate connections, adapters or attribute contracts. The Keycloak server guide warns that this export process has limitations as a backup and restore mechanism, and that all nodes must be stopped while it runs. Use the realm export only to move Keycloak realms between Keycloak instances, and plan a maintenance window for it, since a production cluster has to stop before the export starts. Keep the PingFederate archive and your inventory as separate records and do not expect one to populate the other.
Treat the inventory as a design input for your Keycloak realms. Each SP connection, OAuth client and certificate you listed needs a decision: which realm will hold it, whether it becomes a Keycloak client with a matching protocol, and which attributes the relying party expects. Map PingFederate adapter and attribute contract fields to Keycloak protocol mappers and user attributes by hand, and record each mapping in a table with the source field, the target mapper and the owner who approved it. Note also that private keys in the archive must be handled as secrets, so import certificates into Keycloak through a controlled process rather than copying key material from a shared file.
Before any production change, build a test realm that mirrors one representative application end to end. Create the client, mappers and login flow from the inventory, then confirm the token or SAML assertion contents against what the relying party actually consumes. Repeat this for each protocol type in your estate, since OIDC clients and SAML service providers fail in different ways. Ask your team to confirm each mapping in writing before cutover, and keep the test realm available for regression checks after go-live.
What to plan before the PingFederate contract renews or ends
The archive is only one input to an exit. Contract dates, the PingFederate version in use, the people who must approve the move and the choice between upgrading and moving to Keycloak all shape how and when you export. Confirm each item below with Ping in writing and in your own environment before you start.
Subscription and support end dates
Find the date your current subscription and support terms end, and whether any notice period applies to renewal or non-renewal. Ask Ping to confirm both in writing, including what support you keep during any transition window. Your export schedule should start well before that date, because an archive exported late leaves no room for testing or rollback.
PingFederate version and support window
Record the exact PingFederate version in each environment, including production, staging and any disaster recovery node. Check its support window under Ping's end of life policy, which distinguishes Long-Term and Short-Term Support versions with different maintenance periods. Confirm with Ping whether Extended Limited Support is available and what it costs, since that changes the upgrade-or-move comparison.
Time to export, inventory and test
Plan separate time for the export, the inventory of connections and OAuth clients, and a test run in a non-production Keycloak instance. Effort depends on how many SAML and OIDC connections exist, how many use custom adapters and how many certificates need replacing. Ask your team or implementation partner for a written estimate based on your inventory, not on a general rule.
Sign-off from owners and staff
Identify the owner of each relying application, the security team that approves certificate and key handling, and the staff who will operate Keycloak after cutover. Each connection needs an owner who confirms its redirect URIs, attribute contract and logout behavior. Without those sign-offs, the inventory stays incomplete and cutover slips.
Archive and key handling after exit
Archives contain private keys, so decide where they are stored, who can open them and how long they are kept while the migration runs. Plan secure deletion of every archive, backup and exported certificate once the migration is accepted and any records you must keep are archived under your own retention policy. Confirm with your security and legal teams what they require before the contract ends.
Upgrade or move to Keycloak
Decide whether to upgrade PingFederate to a supported version or move federation to Keycloak. Upgrading keeps the current connection model but carries recurring Ping costs. Moving requires mapping adapters and attribute contracts to Keycloak flows and mappers, and it does not cover WS-Federation relying parties. Compare both options against the same inventory before you commit.
Questions teams ask before exporting PingFederate configuration
How much effort does a complete PingFederate export and inventory take?
The effort depends mostly on how many connections you run, how many of them use custom adapters, and how many certificates and signing keys the archive will reference. The export itself is a single action in the admin console, but the inventory is where the time goes: each SAML connection, OAuth client and certificate needs a row that records its owner, protocol, endpoints, attributes and renewal date. A deployment with a few dozen relying parties and a handful of certificates is a very different job from one with hundreds of connections across several environments. Ask Ping or your PingFederate administrator for an export of the connection and client counts before you plan the work, and ask any implementation partner to base its quote on those counts.
Can our team run the export and inventory without outside help?
A PingFederate administrator can usually produce the archive alone, because it is a download from System, Server, Configuration Archive. Building a usable inventory needs more than that. The work requires someone who understands SAML metadata, OIDC clients and OAuth scopes, someone who can read certificate chains and expiry dates, and someone who knows which adapters and attribute contracts each application depends on. Smaller teams often handle the export in-house and bring in an outside team for mapping and cutover. Confirm internally who holds each of those skills before you decide, and treat any gaps as scope items.
What do application and business owners need to provide?
The archive does not record who uses each connection or why it exists, so the business and application owners supply that context. For each relying party, they need to confirm the owner, the users it serves, the attributes it expects, the business criticality, and any planned retirement. They also need to flag connections that are unused, duplicated or tied to a contract with a third party. Without these answers, the inventory lists configuration but not decisions. Schedule short reviews with each owner early, because their availability often sets the pace of the project more than the technical work does.
Can a PingFederate archive from one version be imported into another?
No. PingFederate does not import an archive from an older or newer version, so you cannot use an export from one release to load a different release. If you plan to upgrade PingFederate before moving to Keycloak, export the configuration from the current version first and keep that archive as a record. For the Keycloak migration, the archive is a source for your inventory, not a file you import into the new platform. Keycloak has its own realm export and import format, which you build from your inventory rather than from the PingFederate archive.
What happens to the PingFederate license file during an export?
The license file is not part of the configuration archive, so exporting the archive does not copy it. The archive also omits adapter and plugin drivers, logs, cluster files and user-facing email and HTML templates. Store the license file separately, and keep a record of which components you run, such as custom adapters and integration kits, because you will need that list to recreate their behavior or retire them. Confirm your license entitlement, renewal date and any support terms with Ping before the migration plan is final, since those terms determine how long you can run the platform during cutover.
How should we handle the private keys inside the archive?
Treat the archive as a secret. PingFederate archives contain private keys, and Ping warns that sharing an archive is a security risk. Store it in an encrypted, access-controlled location, limit who can open it, and record every copy you make. Do not send it by email or attach it to a ticket. Once the inventory is built, decide which keys will be reissued for Keycloak and which will be carried over, then delete unneeded copies on a documented schedule. Your security team should set those rules before anyone runs the export, and the export should be logged in your change system.
What would a consultant scope in a fixed-scope export and inventory engagement?
A fixed-scope engagement is agreed in writing before work starts, so the scope should name the deliverables. Typically that includes reviewing the archive contents against what it omits, building the inventory of connections, OAuth clients and certificates, mapping each item to an owner and a target Keycloak client or realm, flagging unsupported dependencies such as WS-Federation or custom adapters, and documenting how the private keys are handled. Ask for the exact list of deliverables, the systems and environments in scope, the owner interviews included, and the review process. DeployOpen plans and documents these migration preparation tasks in the client's own environment, and the written scope determines the quote.
What does Keycloak do with an exported PingFederate configuration?
Keycloak does not import PingFederate archives. You use the inventory to create realms, clients, identity providers and user federation settings in Keycloak, either by hand, by scripts, or by writing realm JSON that you load with the kc.sh import command. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so SAML and OIDC connections map directly to Keycloak clients. WS-Federation and WS-Trust are not covered by Keycloak, so list any relying party that depends on them before you commit to the target. Keycloak's own documentation also warns that its export and import process has limitations as a backup mechanism, so do not treat a realm export as your backup.
How DeployOpen scopes and delivers a PingFederate export and exit plan
DeployOpen treats the PingFederate export as the start of an inventory, not the end of the job. We work from the archive, the live admin console and your application owners to build a written picture of what each connection, OAuth client and certificate needs before any Keycloak realm is built.
How we scope
- Written scope lists which PingFederate nodes, archives and environments the export inventory covers, agreed before work starts.
- Scope names the applications and relying parties in the inventory and states which items need a separate workstream.
- Scope defines who receives the archive, where it is stored and how private key material is handled during the engagement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We compare each archive against the live console to record items the archive omits, such as adapter drivers, templates and the license file.
- We map each SP connection, IdP connection, OAuth client and certificate to an owner, protocol, endpoint and renewal date.
- We flag connections that depend on WS-Federation or WS-Trust, which Keycloak does not cover alone, and record them separately.
- We test the inventory against a non-production environment so gaps surface before any cutover planning starts.
How we hand over
- The inventory workbook lists each item, its source, its target Keycloak object and the owner who must confirm it.
- A secrets handling record documents where exported private keys were stored, who accessed them and when they were destroyed.
- The exit plan sets out the decision points for each application, including which connections move first and which run in parallel.
- Handover includes a walkthrough with your identity, security and application teams so they can challenge the findings.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the inventory is delivered.
- A retainer can cover updates to the inventory as applications change during the PingFederate to Keycloak migration.
- Support can extend to Keycloak operations, including backups, upgrades and documentation for your own infrastructure.
- Ask any provider to confirm in writing which items remain your responsibility after handover.
