Client Use Cases

Some common client use cases for our DMM users are:

• Clients want to have data available in their new OutSystems apps and are therefore migrating data from “legacy” apps (Lotus Notes, Access, VBA apps, PHP, etc.) into the OutSystems platform.
• This is very relevant when the client is betting on the OutSystems platform for digital transformation projects, attempting to resolve shadow IT issues, or diminishing their dependency on different (often old) technological stacks.

• Clients perform Data Migration from production environment data into QA and development environments to avoid production problems and spending extra time and money due to poor data available to developers or the tester’s ability to comprehend the production impact.

• Sometimes clients need to upgrade the OutSystems version in a parallel environment, instead of upgrading in the current installation.

Some examples:
– The client wants to upgrade app by app and not the whole environment at the same time.
– There is some risk in having different platform versions in development/QA/production. For example, if something happens in production when development and QA are in another version it has to be solved directly in production or put on hold for that environment to upgrade.
– If the new version doesn’t support the same stack. For example, clients who are using a MySQL/Java stack and planning to upgrade to OS11, which doesn’t support this tech stack.

• We can migrate data between versions 8, 9, 10 and 11.

• Some clients have special data backup requirements where a full database backup is not feasible.

For example, imagine there is a business app with critical data in a big multi-app OutSystems environment with a very large database, and their disaster recovery plan (DRP) needs a fast continuous information backup of just that critical app data.

• The client is changing technological stacks or architecture.

For example, we support data migration between:
– OnPrem <-> Cloud (either client Cloud or OutSystems PaaS Cloud in Azure, AWS, or another platform)
– MySQL -> SQLServer, or MySQL -> Oracle
– SQL Server <-> Oracle

• When the tests (performance, security, or penetration tests) are done in a non-production environment, there is a need for “good data”—either in volume or quality—to mimic production.

• For GDPR compliance, clients need to easily guarantee on data cleaning processes (either scrambling, anonymizing or deleting data at rest).

For example, the client was using production data in other environments and wished to scramble/anonymize it or the client’s client evoked the “right to be forgotten,” but instead of deleting data records for some business or BI reason, it was best to just anonymize or clean the personal fields involved, keeping the rest of the record.