Main Features

Support migrations for Microsoft SQL Server, Oracle and MySql databases

You can set up your migrations between databases in any of the above technologies. It is even possible to set up a migration from one database technology to another. The current possible combinations are:

●     From MS SQL to MS SQL or Oracle

●     From Oracle to MS SQL or Oracle

●     From MySQL to MS SQL or Oracle

Support for OnPrem, OutSystems PaaS Cloud (with Runtime Connection) or Private Cloud Scenario

Infosistema DMM only requires direct connectivity to the databases. In cloud scenarios, it is possible to use the OutSystems Runtime Connection to perform reads and writes in the necessary Entity Tables, out-of-box.

Support for OS8 through OS11

Infosistema DMM supports migrations from OutSystems 8 to the latest version, 11. You can even migrate data between versions!

The frontend of DMM is available on the OutSystems Forge for both 11 and 10 versions of OutSystems.

BPT migration

Infosistema DMM can migrate BPTs / workflows between different OutSystems instances. 

These include also BPTs not connected to any entity, and BPTs will be copied with their current instances status.

DMM also allows for the migration of the Emails associated with the BPT processes.

Delta Migrations

Let's say you have 2M records and perform a first delta migration today to an empty destination environment.

Next week you now have 2.1M records - but in that volume you may have new records, changed records and removed records.

With the Delta Migration functionality, DMM will detect what changed regarding the last Delta Migration and will only issue commands accordingly, thus this new migration will be faster as the amount of data migrated is much smaller.

Two immediate pratical applications:

• Continuous update of a quality environment;

• One shot migration with low downtime but big amounts of data (the period between deltas can be used for the migration team to evaluate the quality of the destination environment)

Scrambling and Anonymization

This feature ensures the transformation of data during migrating to the destination database.

With scrambling, data will keep its semantic value but will not have a correlation to the source data, i.e. an email field will hold text that looks like email addresses, which may even be valid email addresses, but ones that will not exist in the source data. The same applies to dates, names, credit card numbers, bank account numbers, phone numbers, zip codes, etc.

Using anonymization will cause the destination values to become a meaningless garbled text, which ensures the process complies with GDPR.

Exporting

You can extract data from your OutSystems environment and download it in CSV format, which is ready to be used in any ETL process you need or simply to be archived.

You can also EXPORT DATA DIRECTLY TO AN EXTERNAL DATABASE (non-OutSystems). With this feature DMM will create the external tables/columns as needed, and in subsequent migrations will update the records matching them by their IDs.

Importing

You can import data previously exported with Infosistema DMM or filled with some ETL process into a defined CSV structure of the OutSystems business tables obtainable/exported from Infosistema DMM. This allows for bulk importing of data from non-OutSystems applications, bringing that data into your OutSystems environment.

Data source Filtering 

DMM allows you to define filters to apply during migration thus allowing full control of what is migrated between environments.

User Mapped Table

This allows the operator of Infosistema DMM to flag a table as being "User Mapped" and stating what column will be used to map information from the source to the destination. This column should have unique values and will be used instead of the ID Column to detect if data should be updated or inserted in the destination database.

Automatic detection of table dependencies

At configuration, DMM will check your picks and suggest other entities that should also be migrated to guarantee data consistency.

Separation between configuration and execution

Allows setting up automation for actions you do repeatedly.

Site Properties Migration

Allows for migration of the current definition of site properties, instead of their default values.

Health Check

Perform a validation / health check on your OutSystems data, if it is coherent and identifying potential issues.

Data Compare

Compare data in entities in different OutSystems environments.

Scheduling

Once a configuration of an operation (Migration, Export, Delete, Scramble, etc.) is made, you can schedule it to be executed in the future or repeatedly at a certain intervals. You can also sequence operations to be done one after the other.

Besides this feature out-of-the-box with DMM, you can also use external schedulers (with DMM's web API), or configure your own OutSystems Timers (the demo app on the Forge has examples).

Current Main Limitations

●     We will not stop the databases, disable triggers nor change in any way the database or the applications. As a best practice, we recommend stopping or pausing the databases and applications that will be involved in a migration process to guarantee that data is moved as an atomic operation thus reducing the occurrence of inconsistencies in the database. When migrating BPTs we clear the related EVT data, thus preventing new processes to start.

●     We will not delete nor purge any existing data in the destination database when Standard Migrating or Importing data (we do when using the Deletion, Data Clean or the Delta Migrations functionalities). If the destination database is not clean, information from the source will overwrite existing information or append information. Records that exist in the destination but do not exist in the source will be kept untouched. In some scenarios, migrations may fail if unique constraints are disrespected.

●    Tables without a primary key: the data on these tables will always be appended if the entity is picked for migration.

●    File System access:  For performing Exports or Imports Infosistema DMM will save the temporary files on the server path, so it requires read and write permissions over a folder on the machine where it's being executed. A specific folder is provided for the OutSystems Cloud PaaS.  Meaning within DMM's environment and needed only for the Import/Export features, the IIS user must have “read” and “write” permissions to the folder specifid in the DMM Settings (in the OutSystems PaaS Cloud, the value to be configured is "D:\User\InfosistemaDMM").

●    The Forge OutSystems Component requires an OutSystems version 10 or version 11 on a .NET infrastructure.

●    Data Deletion  functionality will set FKs to deleted records as NULL (not a limitation, more a feature).

Limitations with already existing workarounds:

 The executing machine must have an internet connection for license validation, if this is not possible, we have a process to enable the license in offline mode.

 For the Data Migration functionality,  the DMM installation must reach both databases that are the targets of the migration—the source and destination databases. Alternatively for the source, a DMM REST Connection can be used (in such case, the destination must be able to reach the origin DMM installation through HTTPS / REST API).

 When migrating from cloud to cloud, if the direct connectivity to the databases cannot be assured, then an export - import approach or the DMM REST connection type  must be used. If the use case involves Data Scrambling, Data Deletion, Data Export or Data Import, then the machine only needs to connect to the intended database.

 It is possible to execute operations directly in the environment where Infosistema DMM is installed by using the preset OutSystems Runtime Connection (the database connection all OutSystems apps can use to access their own environment's database directly). If this connection is selected as the destination for data on execution, the Data Append mode will be activated as the Runtime Connection  does not allow identity comparison between environments.

 Data Append mode may fail in a scenario where the destination environment has data, the structure has a unique column, and data in the source has a record with the same unique value that is already present in the destination. This limitation can be overcome using the User Mapped Table feature in the migration configuration, which may also be used to map tables instead of the natural ID and so circumvent the Data Append and do an update on the records in the destination.