Skip to Content
Technical Articles
Author's profile photo Phil Cooley

How to Migrate SAP Cloud Platform Workflows

I have been part of recent projects that utilise the SAP Cloud Platform Workflow service and one major improvement area I thought of was in the migration and subsequent deployment of the Workflow definitions throughout the SAP Cloud Platform landscape. This of course could differ depending on the subaccount architecture. With this in mind I thought I would post a small blog on how this can be achieved while also offering some ideas about how this can be improved.

This follows on from a number of blog posts that Mike Doyle covered on the Workflow service which I have included links to below.

I will first provide some context around migrating other similar objects in SAP Cloud Platform in general.

Migrating HTML5 Applications

HTML5 applications can be migrated through to other subaccounts by:

  • Exporting the HTML5 application from a subaccount and Importing the application into a different subaccount. The app version can then be activated. e.g. when updating an application from a DEV subaccount to a TEST subaccount.
  • Using SAP Web IDE in the TO subaccount, retrieving the latest code from the GIT repository and then deploying to SAP Cloud Platform.
  • Setting up a New subscription (in the TO subaccount) that calls the application in the FROM subaccount.

From experience, I find the easiest option by far is the first one. A simple export and import of the application is quick and does not require a large amount of security set up to achieve as some of the other options do. Additionally, I believe that developers have access to SAP Web IDE only in the DEV environment just to further control the development activities and codebase (even though I know with GIT this is not a big deal). Following the first option is in line with this approach whereby the 2nd option would require developers to have access to SAP Web IDE in all environments – not ideal. Note: This is my opinion only!

I am interested in pursuing the 3rd option above however have not actively set this up. I am keen over the coming months to come up with various landscape options for SAP Cloud Platform and have submitted a Teched session to cover this – let’s see if it is accepted :-). Stay tuned!!!

Migrating Portal Sites

Portal sites can also be migrated through to other subaccounts. What I have found and experienced in this area is that you do this only once – mainly because the version numbers of all of the applications are not kept so it is hard to manage the versions of applications between the different subaccounts. Definitely areas for improvement here as well however the way I have typically worked around this is by the first option detailed above. Exporting and Importing of the HTML5 applications individually. This ensures continuity of the app versions between environments – assisting with the support and maintenance activities.

Migrating Workflow Definitions

Having said all of the above, the only way I have found to migrate workflow definitions (and to deploy them) is to use SAP Web IDE. This IMO is a limitation. Totally understand given how the technology works why this is the case but this definitely needs improvement from a developer experience point of view. Definitely a candidate for a #FeatureRequestPhil item. 🙂

Additionally, the approach I mentioned above with having developers only in the DEV environment goes out the door with the way the workflow definitions need to be deployed. While it means further planning up front is involved when determining the landscape configuration it is not ideal. I would like a process similar to the export / import option but will cover this further below.

I will now cover the actual process of migrating the workflows.

Migrating Workflows

A number of steps are involved in migrating workflows, this includes:

  1. Migrating the application the WF is included in
  2. Setting up of SAP Web IDE
  3. Importing of the Workflow Application into SAP Web IDE
  4. Deploy to SAP Cloud Platform Workflow
  5. Checking the Workflow Definition has been deployed successfully

Each will be covered in detail now.

Migrating the Workflow Application

Similar to HTML5 applications I think it is good practice to have a self-contained application that is migrated through the landscape that includes the workflow – by itself. In the current project I am involved in a number of different applications were using the same workflow so did not make sense that the workflow would be tied to one of them in the code base. You can deploy the workflow applications to SAP Cloud Platform similar to any other application – the process is the same.

The entire process involves:

  • Downloading the workflow from a subaccount. This should save a copy of the application ZIP file to your local machine.
  • Uploading this into a different subaccount by using the [Import from File] option. Browse for the application ZIP file you just downloaded.Update the name of the Application as well as the version and select [Import].

    The app when first imported will not be active – it will be in Stopped Status.

    Activate it by selecting the application and navigating to the Versioning menu and clicking on the Activate icon as shown below.

At this stage, all we have done is migrate the actual Workflow application across to the new subaccount – we have not deployed this as yet. Keep the ZIP file of the application handy as you will need this for the next step.

Set up Web IDE

In the new subaccount, navigate to the SAP Web IDE service and make sure you have the necessary preferences activated. There is a specific Workflow extension setting required to be activated in order to deploy the workflow.

NOTE: You will need the SAP Web IDE related security roles to perform this step. 

Go to Tools -> Preferences menu option.

Choose [Extensions].

Find the Workflow Editor extension and activate it!

Hit [Save] to make sure this is saved.

Import the WorkFlow Application into Web IDE

Once you have set up SAP Web IDE it is time to import the application. Select the Workspace and then choose the Import option to upload the Workflow (WF) application.

Locate the ZIP file and upload. The app will be uploaded so then open the workflows folder as you can see below.

This completes the importing of the WF application.

Deploy the WF Application

The last step is to actually deploy the WF application to SAP Cloud Platform workflow. The key step here is to make sure you are selecting the workflow and not any of the other components (such as forms, scripts etc).

NOTE: You will need the WorkFlowDeveloper security role to be able to perform this step. 

Select the highlighted workflow model and use the right mouse content menu.

You will then receive a message in the console stating that the workflow has been successfully deployed.

Checking the Workflow Definition

The new workflow definition will be added to the list of definitions within the to subaccount. To check, you can run the Workflow Definition app that has been provided. You can navigate to this via the Portal service.

When the default FLP runs the Monitor Workflows – Workflow Definitions application will be included.

When you run this application you will see your new workflow definition that you deployed earlier.

You can then select the [Start New Instance] if you want to create new instances to test out the generation based on the workflow definition.

That concludes the steps involved in the migration of workflows from one subaccount to another in SAP Cloud Platform. There is SAP Help available on this topic however it was a bit light on – have included the links. Transporting workflows link is here and deploying link is here.


During the project there were a number of improvements I thought of.

  • Easier Deployments

    Definitely needs a better deployment process – especially when deploying to other subaccounts. As described during this blog post the Export / Import option is great and easy for applications so something similar for workflows would be great. The activation of the workflow would then automatically deploy to SAP Cloud Platform instead of the subaccount as the HTML5 applications do.

  • Removal of the Workflow Definition

    There was no function available to remove the workflow definition. I found that once you deployed a workflow definition there was no way of removing it. Of course you could update the version by changing the workflow and then deploying again but you could not delete one. From a maintenance and support point of view would be good to have this function as you could end up with a large number of workflows that are simply not used.

  • Updating of Workflow Instances

    During the project we had to make a number of changes to the workflow definition and there really was no way to update the existing workflow instances (from an earlier workflow definition) so that they are up to date. There was some material around workflow form updates here but not everyday workflow field updates.

  • Automated Destination Configuration for OAuth Security

    We had to call the workflow API’s within an application so needed to configure the OAuth client for SAP Cloud Platform workflow in addition to adding the oauth_client security to the Workflow admin global roles. This was quite tricky at first so would be good to have this automated as part of the OAuth client creation.

Overall the experience we had using the Workflow service in SAP Cloud Platform was a good one – it was really easy to create new workflow definitions and after a bit of time easy to utilise the API’s once the connectivity and security was covered. The migration of workflows throughout the environment was also quite easy although as I stated above it can be improved.

This concludes the how to guide for migrating workflows.

Thanks for reading and as per usual feel free to leave your comments and any experiences you’ve had working with the workflow service – especially in the migration of them.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Peter Gottinger
      Peter Gottinger

      Hi Phil,

      nice blog post. Just wanted to give you a hint:

      With the MTA packaging of Workflows in the CF environment, you would be able to deploy a Workflow easily also to other subaccounts (even with the command line if you want to).

      Best regards,


      Author's profile photo Phil Cooley
      Phil Cooley
      Blog Post Author

      Thanks Peter Gottinger - appreciate that. Yes, I've yet to get my hands dirty with workflows in the CF environment. Looking forward to it so will take a look at this in the near future.

      Thanks for the additional information though!


      Phil Cooley

      Author's profile photo Vikas Rohatgi
      Vikas Rohatgi

      Dear Phil,

      SAP Cloud Platform Transport Management Service in SAP Cloud Platform Cloud Foundry Environment helps in transporting the content from one sub account to another one. Following link will be helpful in understanding the mentioned service:

      Now, Workflows can be modelled as part of Multi Target Applications(MTA) in Cloud Foundry environment. You can build the MTA which generates the .mtar file containing application modules. Using the Transport Management Service, mtar file can be transported to the different sub accounts very easily. This service eventually transports all the modules (UI, Java, FLP, Workflow etc.) which are part of the MTA to the target nodes (target sub accounts) together as part of one transport action.

      Best Regards,


      Author's profile photo Stefan Henke
      Stefan Henke

      Hi Phil.

      there is also the option to undeploy workflow definitions via API:

      DELETE /v1/workflow-definitions/{definitionId}

      For reference, you can check the API documentation:


      Best regards,

      Author's profile photo Phil Cooley
      Phil Cooley
      Blog Post Author

      Thanks Stefan Henke I will add that to the improvement idea so others know it is a feature. Ideally though would be great to include in the Workflow Definitions app itself (rather than going through the API to delete it). Better user experience for Administrators that's for sure.

      Thanks for pointing this out though!


      Phil Cooley

      Author's profile photo Mike Doyle
      Mike Doyle

      Hi Phil Cooley I agree that the export/import works well with html5 applications and would be a good model for workflows in Neo.  Couldn't the export/import happen in the Monitor Workflow Definitions App?

      Given the current features in Neo, isn't the easiest method just cloning the repo in Web IDE (in test or prod) then deploying the workflow from there?  I agree it would be better if we didn't need to use Web IDE in test and prod.  Previously, with Fiori Mobile, I created dev, test and prod branches in the GIT repo, in order to manage flow of fixes dev->test->prod

      I agree that this will be moot in CF, because the MTA can be deployed to downstream systems using the CLI

      I'm not surprised that you can't change the definition version number that a given instance uses.  Otherwise every time you make a change to the workflow you would have to consider the consequences for live instances 'upgrading' at every step.  For example, perhaps the new version has an additional variable in the context, which won't exist in the 'old' instances

      Good to know that you can delete definitions using the API, but what happens if you have already created instances using that definition?  Perhaps an active/inactive concept would make more sense


      Author's profile photo Phil Cooley
      Phil Cooley
      Blog Post Author

      Interesting idea Mike Doyle - there would presumably need to be a button there for deployment or does this automatically happen when you import? Sounds good though.

      Cloning the repo or doing export/import to me are pretty much the same thing, in terms of the same problem of having to launch Web IDE to do this activity.

      I think it is great that the MTA is available in CF however there needs to be better options offered to those customers with Neo as well. Not every customer will subscribe to CF in fact most in my experience just have Neo. Hopefully this starts to change given the great offerings in CF however at the moment this is not happening.

      Yeah, I am definitely simplifying the activities around workflow definition changes however the reality is business processes are complex and especially during project development activities there is a need to change the workflow definition so exploring options of realigning instances or some other similar concept would be a good offering.

      Thanks for your comments on this topic.