If an organization decides to stop using OutSystems, the generated applications can be generated one last time, detached and deployed to a standard web application server stacks. There are a few things to do before the code is detached. There are also dependencies to be considered.
Viewing the source code without detaching
Before detaching the source code
Since there is a close mapping between the visual model and the generated code, we recommend that someone who understands the business logic of the original application built in OutSystems maps the logic in code to the visual logic in the application, and transfers this knowledge to those who will be running and operating the application in the future. There should also be developers on hand who understand underlying stack technologies and standard .NET / ReactJS application architectures and code written in the corresponding languages.
If an organization decides to detach its source code, it must also take the following into account:
Access to all the application development, management and operation capabilities of OutSystems platform will be lost.
Embedded feedback, performance monitoring and logging capabilities will require other tools.
All of the OutSystems tools and services, along with their features, will become unavailable. This includes the visual development environment, the integration environment, the environment management console, and the infrastructure management console. However, all core functionality of the applications developed within the IDEs will be retained.
All dependencies of the generated source code, necessary to execute the application outside of OutSystems, must now be tracked. These dependencies include OutSystems services, OutSystems runtime libraries and databases.
There is no reverse engineering process to get the applications back into the OutSystems platform from the generated code. If you want to go back to using OutSystems, you can do so by using the latest versions of your application models. Once the database is operated outside of OutSystems, you will need to resort to ETL or other data loading processes to load data back into the OutSystems platform environments.
Our commitment to helping our customers who want to terminate their subscription and detach their applications will be the same as if they were any other kind of customers. Anyone who needs any help detaching applications from OutSystems, can call their account manager or OutSystems Support.
Detach and OutSystems Cloud
If you're subscribed to OutSystems Cloud, to detach your applications, you need to first setup a hybrid deployment, where you install one OutSystems environment either on-premises or on another public cloud infrastructure (e.g. Amazon AWS, Azure).
All the instructions below assume you already have completed this installation.
Check the detailed steps to complete a transition from the OutSystems Cloud to on-premises.
How to detach the source code
To detach the source code of your applications and stop using OutSystems:
Compile and build your applications with Visual Studio. The project files extracted from Service Center contain all the resources and dependencies for compiling and building the applications with a standard .NET integrated development environment like Visual Studio. You can then deploy the application into an application server.
Migrate your databases/schemas to a new database server (optional)
Your application’s data is reusable, either by using the same database server or by detaching/backing up the existing databases/schemas from the current database server and attaching/restoring them to a new one.
How to handle source code dependencies
After an application is detached, the source code will still have external dependencies. These dependencies include OutSystems services, OutSystems runtime libraries and databases. They must be handled differently after detachment.
OutSystems Services and the Scheduler Service
A set of code optimizations and services won’t be available once OutSystems is no longer used. This includes the Log Service, the Deployment Services, Service Center, and LifeTime. These dependencies will be removed, along with the probes that monitor health and performance (which are automatically added by OutSystems) and automated deployment and configuration management.
Organizations who are using time-based batch processing logic will be able to keep this functionality even after detaching the source code. The source code of the Scheduler Service will be provided for this purpose. This dependency can be removed manually if a decision is made to handle this with a different external tool.
OutSystems runtime libraries
The source code of OutSystems libraries required by applications is open and available. This means that this code can be changed. Even if the applications initially require that code, they can be changed to remove this dependency.
Data models, as defined in the applications, are created and updated in the database without any extra effort and without resorting to special database configurations and complex management expertise. During compilation and publishing, OutSystems generates standard differential SQL DDL (Data Definition Language) scripts that are executed over the runtime database. The generated source code assumes the model is properly created (both schema and configuration data) and depends on each specific database vendor driver, SQL syntax, and other specificities.
A decision to use a different database server after leaving OutSytems will require that databases, schemas or both, be manually moved and the application server configured accordingly. Notice that the SQL scripts to create and populate the database and/or schemas are not provided by OutSystems. Also, the application’s source code will have to be changed to make it compliant with the new database engine.