New Capability: Source Migration From VA to SaaS Source

:double_exclamation_mark: SailPoint is excited to announce that specific sources connected to virtual appliance (VA) clusters can be migrated to SaaS connections.

This ensures data (users and entitlements) remain intact, which maintains your source specific configurations, access modeling like access profiles, roles, password settings, and correlation configurations when switching from a VA cluster to a SaaS connection.

When you choose to migrate from VA to SaaS, a draft version of your source is created to validate credentials and test the connection, while your live source continues running until you apply the migration. This helps ensure a smooth transition with no interruption to production.

Key things to know before migrating:

  • No additional configuration is required beyond re-entering connection credentials.
  • Draft changes won’t affect your live source until the migration is applied.
  • Once applied, the migration is permanent.

Connectors supporting Migration Capability

This new capability provides a secure, low-impact way to modernize your connections and move away from VA cluster dependencies. Learn how to migrate in the full documentation:

1 Like

Looks interesting! :grin:

This makes me wonder. How will the connector rules used for those sources get migrated to ensure the same behaviour is noticed? Or could it be that the migration will break if the customer is using connector rules?

Referring to:

EDIT: I think I answered my own question as the currently listed supported connectors for this migration all don’t seem to support connector rules anyway, so then this would be irrelevant here. It would become relevant once it becomes possible to migrate Web Services sources to Web Services SaaS sources, which I would definitely be interested in :grin:

A different but relevant question would now be: If we use a Before Provisioning Rule, which listens to some (custom) source connector attributes. Will those connector attributes then also get migrated automatically to the replacement source?

Kind regards,
Angelo

1 Like

Are there any plans to expand this capability to other Connectors? If yes, can you share the planned roadmap for other Connectors?

Is there something that needs to be enabled in our tenants to be able to use this feature? I have looked in both our Sandbox and Production tenants and do not see Migrate to SaaS on any of the VA connectors listed above.

Hey Carl! Good question, which connector are you looking for this option?

Atlassian Cloud, Box, Duo

Thanks Carl, let me find an answer for you. I will let you know when I have an update.

Hey Carl! We should have an update on this on Wednesday. Thanks!

Hi @Carlatto, you can check the Migration option now in your Org and let us know if there is an issue. Thanks!

I see it in our tenants now. Was there something that needed to be done to our Tenants?

Hi @ChristopherS, thank you for your interest on this capability. Yes, there is a plan for other VA based cloud connectors as well (other than the generic connectors).

You will see an update before mid of December. If there is any specific connector that you are looking for, then please let me know. Thanks!

Hi Carl, we enabled these connectors as per the segments and it got cover for your tenant recently. Thanks!

Hi @angelo_mekenkamp,

This makes me wonder. How will the connector rules used for those sources get migrated to ensure the same behaviour is noticed? Or could it be that the migration will break if the customer is using connector rules?

  • You are absolutely right that there is no connector specific rules for these list of connectors. :slight_smile:

A different but relevant question would now be: If we use a Before Provisioning Rule, which listens to some (custom) source connector attributes. Will those connector attributes then also get migrated automatically to the replacement source?

  • Any cloud rule will work as it is, that includes before provisioning rule. Just make sure that attributes are correctly configured in the source schema (if it is not there.)

Thanks!

Thank you for your response @dinesh_mishra!

Perhaps I should clarify the second question a bit more. If our original source has in its JSON within connectorAttributes a field like ourCustomVariables: {…}, which we use for the before provisioning rule. Will these fields then be automatically migrated to the upgraded SaaS source when we hit migrate source?

If not, migrating to the SaaS source will not automatically work. It would break the integration unless we take into account the manual work needed to migrate these fields ourselves. Not a big issue, but good to know this is a requirement. Especially if we plan to migrate many sources to the SaaS equivalent.

And will the migrated source keep the same id?

Kind regards,
Angelo

Hi @dinesh_mishra , Azure, Workday, SAP Concur, and Snowflake would all be great.

1 Like

Hi @angelo_mekenkamp,

If our original source has in its JSON within connectorAttributes a field like ourCustomVariables : {…}, which we use for the before provisioning rule. Will these fields then be automatically migrated to the upgraded SaaS source when we hit migrate source?

  • Yes, schema will be intact. If you have added a custom field for the applicable connector, then that will be also available after Migration. Also, as I mentioned cloud rules will remain same.

And will the migrated source keep the same id?

Yes, migrated source keep the same ID. All aggregated data, access model, running certification will remain as it is.

Thanks!

1 Like

Exactly as it should behave. Thanks!

1 Like

Appreciate the capability. Before we recommend this for broad customer adoption, I want to validate the “credentials-only” message in real enterprise environments. Many customers rely on Cloud Rules (especially Before Provisioning) that reference custom connector attributes and schema extensions to enforce policy and ensure consistent outcomes.

To avoid any unexpected changes in access outcomes post-migration, can you confirm:

  • Custom connectorAttributes are migrated unchanged

  • Custom schema fields/extensions remain preserved

  • The Source ID stays the same (so existing access models, certifications, reporting, and historical data remain consistent

A simple “what migrates / what doesn’t” checklist in the docs would reduce risk and make this much easier to adopt at scale.

Hi @amrdodani! We’ve updated the documentation to provide more details around schema handling during migration. Hopefully this provides more clarity. Thanks for helping us improve the docs!

Hello @dinesh_mishra,

Do you know if the “SAP Concur” connector is planned to support this feature?