As discussed on 27th August 2026 with @SoniaPetrescu and @sapgunnar , it would be good to have a normative recommendation from SAP that customers should gradually migrate all solutions from ".ondemand.com" etc. to the common superdomain ".cloud.sap".
Here's first draft.
SAP uses various second level and top-level domains for cloud solutions (e.g. *.ondemand.com, *.cloud.sap, *.ariba.com, *.successfactors.eu etc.). The announcement by Google about the deprecation of third-party cookies triggered SAP to start unifying various solutions to a single common superdomain (*.cloud.sap). However, the deprecation of third-party cookies in browsers has since been postponed/rolled back by Google and thus the strongest raison detre for a migration to *.cloud.sap was rendered moot.
In general, it has been possible to resolve any issues pertaining to heterogeneous superdomains (mixture of *.ondemand.com and *.cloud.sap. in the environment) without necessarily migrating solutions to *.cloud.sap. Therefore, the migration to *.cloud.sap can be considered as a low priority. Also, if there are any new issues that arise with SAP products relating to these domain names, it will generally fall within the scope of standard support to find a solution and/or workaround.
SAP Cloud Identity Services can be accessed from either superdomain e.g. with "https://<tenant>.accounts.ondemand.com" or "https://<tenant>.accounts.cloud.sap". Also, SAP Cloud Identity Services now supports synchronisation of session cookies for both domains (which can be enabled by the customer in the SAP Cloud Identity Services tenant as a self-service in Applications & Resources → Tenant Settings → Single Sign-On → Sync SSO Cookies Between Domains). This feature in SAP Cloud Identity Services has allowed for successful integration of Joule in SAP landscapes with heterogeneous superdomains.
Nevertheless, there are various reasons why customers should consider migrating all of their solutions to the common superdomain *.cloud.sap.
- Less configuration needed for end-user devices. As documented here, in cases where
*.ondemand.com is used with SAP-Managed Joule, the customer must ensure that third-party cookies are allowed on end-user devices. When using the common superdomain this step is not required.
- Lower probability of technical issues. If all solutions in the customer landscape use the common superdomain
*.cloud.sap, we perceive that there is a lower probability of any novel issues affecting the systems.
- Clarity for end-users. We perceive that the superdomain
*.cloud.sap provides the best clarity and meaning for the lay end-user. When a lay user logs on to an application with the *.cloud.sap superdomain they can easily guess that the solution is: a. operated in the public cloud and accessed over the public Internet; and b. operated by SAP. These inferences are less easy to infer from a domain like *.ondemand.com.
Therefore, in the general case we recommend that customers should migrate all SAP cloud solutions to ubiquitously use the common superdomain *.cloud.sap. However, this migration is not a strict prerequisite for Joule or any other technical integration. We also acknowledge that such a migration could involve significant effort and collaboration with various SAP support teams and therefore should be considered carefully in terms of cost and benefit.
As discussed on 27th August 2026 with @SoniaPetrescu and @sapgunnar , it would be good to have a normative recommendation from SAP that customers should gradually migrate all solutions from ".ondemand.com" etc. to the common superdomain ".cloud.sap".
Here's first draft.
SAP uses various second level and top-level domains for cloud solutions (e.g.
*.ondemand.com,*.cloud.sap,*.ariba.com,*.successfactors.euetc.). The announcement by Google about the deprecation of third-party cookies triggered SAP to start unifying various solutions to a single common superdomain (*.cloud.sap). However, the deprecation of third-party cookies in browsers has since been postponed/rolled back by Google and thus the strongest raison detre for a migration to*.cloud.sapwas rendered moot.In general, it has been possible to resolve any issues pertaining to heterogeneous superdomains (mixture of
*.ondemand.comand*.cloud.sap.in the environment) without necessarily migrating solutions to*.cloud.sap. Therefore, the migration to*.cloud.sapcan be considered as a low priority. Also, if there are any new issues that arise with SAP products relating to these domain names, it will generally fall within the scope of standard support to find a solution and/or workaround.SAP Cloud Identity Services can be accessed from either superdomain e.g. with "https://<tenant>.accounts.ondemand.com" or "https://<tenant>.accounts.cloud.sap". Also, SAP Cloud Identity Services now supports synchronisation of session cookies for both domains (which can be enabled by the customer in the SAP Cloud Identity Services tenant as a self-service in Applications & Resources → Tenant Settings → Single Sign-On → Sync SSO Cookies Between Domains). This feature in SAP Cloud Identity Services has allowed for successful integration of Joule in SAP landscapes with heterogeneous superdomains.
Nevertheless, there are various reasons why customers should consider migrating all of their solutions to the common superdomain
*.cloud.sap.*.ondemand.comis used with SAP-Managed Joule, the customer must ensure that third-party cookies are allowed on end-user devices. When using the common superdomain this step is not required.*.cloud.sap, we perceive that there is a lower probability of any novel issues affecting the systems.*.cloud.sapprovides the best clarity and meaning for the lay end-user. When a lay user logs on to an application with the*.cloud.sapsuperdomain they can easily guess that the solution is: a. operated in the public cloud and accessed over the public Internet; and b. operated by SAP. These inferences are less easy to infer from a domain like*.ondemand.com.Therefore, in the general case we recommend that customers should migrate all SAP cloud solutions to ubiquitously use the common superdomain
*.cloud.sap. However, this migration is not a strict prerequisite for Joule or any other technical integration. We also acknowledge that such a migration could involve significant effort and collaboration with various SAP support teams and therefore should be considered carefully in terms of cost and benefit.