I'm evaluating the possibility of migrating our OutSystems applications from the Public Cloud (PaaS) to another cloud provider, either Azure or AWS, primarilly in order to gain full control over the database.

There is lots of information available about how to install on other cloud providers, for example this guide for installing on Azure. But that relates to a fresh install, not a migration. There seems to be very little information about migrations, with this article being all I could find.

So, some specific questions:

  • The second link above says to use third party tools or create your own tool to migrate data. Is it not possible to simply do a database backup (from OutSystems Public Cloud) and then restore into the new environment?
  • The same link also says to contact support about migrating metadata. Does "metadata" include the actual applications? I'm not ready to speak to support yet, I'm just in the planning stage and trying to get a high-level understanding of the process, but how would moving the applications work in practice? What would support do/say when I contact them?
  • Is any downtime needed? I presume that I'll need to take a copy of my data, then prevent access to the system until the migration is complete... otherwise, users will be writing to the old database instead of the new one. How have people managed this in the past?

Any insights welcomed!


Let me start by stating that this migration will not be an easy process. I'm in the process of migrating 2 on-prem environments to the cloud. One to Azure and one to the OutSystems PAAS. But what you need is the other way around. 

I don't think you'll be able to a backup/restore of the database. Instead you'll have to use 3rd party tools like the DMM of Infosistema (https://www.infosistema.com/dmm-data-migration-manager/ ). I recently started testing that one but I haven't tested all use case yet. But it looks very promissing.

Since there's no backup/restore, the best approach would be to create new environments in your own cloud environment en migrate application by application, environment per environment. Migrating the code is easy. For the data, the DMM or another migration tool can help. This phased approach is also the less risky with regards to downtime and migration issues as you can take it step by step.

Depending on the data of database (Oracle or SQL Server), there might be some other options but since you start from the PAAS where you don't have direct access to the full database, I don't think those will work.

I see another issue with Lifetime. Even the DMM connat migrate that data. But recreating the roles/teams manually should be that big of a deal as the number of items normally will be limited. For the LifeTime users, it depends on how many you have. Creating a script might be handy. We'll also have to do it but I need to look into that.

I hope this clarifies things a bit. If not, let me know.