Data correction using patches during migration

Kazuna Fujimori

Question

Hello team

I understand that in OutSystems, patches are usually applied to fix bugs or address security issues in the platform.

I would like to ask whether it is possible to use patches for data correction purposes during a server (data) migration.

What we are trying to do is the following (O11) :
When migrating to a new server, we also need to migrate existing data.
During this migration process, global data correction or adjustment is required.
We are considering whether it is possible to use a patch mechanism to apply such data corrections.

As an OutSystems mechanism, I understand that patches can be applied for bug fixes and similar purposes.
However, I am not sure whether patches can be used as a method for data correction,
rather than for fixing platform defects.

Specifically, I would like to know :

Can patches be used to perform data correction during server or data migration?
Are there any limitations, constraints, or risks when using patches for this purpose?
Is there a recommended or standard approach in OutSystems for handling large-scale data corrections during migration?

Any guidance or best practices would be greatly appreciated.

Thank you in advance.

27 Jan

Miguel Verdasca

Champion

Hi Kazuna...
The following answer is just my opinion, based on my experience. Please do a double check with the OutSystems documentation.

Short answer: No, patches are not the right mechanism for data correction during migration.

In OutSystems (including O11), patches are intended to address platform defects, hotfixes, or urgent corrective changes to the application logic, not to perform functional data transformations or mass data corrections.

To your specific questions:

1. Can patches be used for data correction during server or data migration? Technically, a patch could execute logic that updates data, but this is not supported nor recommended. Patches are not designed for controlled, repeatable, or auditable data migration or correction activities.

2. Limitations, constraints, and risks Using patches for data correction introduces several risks:

Lack of idempotency: patches are not designed to safely re-run.
Poor traceability and auditability of data changes.
Risk of unintended side effects if the patch is re-applied or partially executed.
Operational risk during platform upgrades or environment synchronization.
Misalignment with OutSystems lifecycle and support practices.

Because of this, OutSystems Support would generally discourage or refuse this approach.

3. Recommended approach for large-scale data correction during migration The standard and supported approaches are:

Dedicated migration utilities or scripts (SQL scripts, ETL tools, or external migration jobs), executed in a controlled manner.
Temporary OutSystems modules with explicit migration logic, versioned and executed once, then retired.
Pre- and post-migration data validation and reconciliation steps, separated from the application lifecycle.
Use of idempotent migration logic, with clear checkpoints and rollback strategies.

In summary, patches should be reserved for what they are meant for: application hotfixes. For data migration or correction, use explicit migration mechanisms that are traceable, repeatable, and operationally safe.

Hope this helps clarify the recommended path.

Best, Miguel

27 Jan

Kazuna Fujimori

@Miguel Verdasca

Thank you for the detailed explanation.

I understand now that patches are not intended or recommended for data correction during server or data migration, even though it may be technically possible.

Based on your explanation, it makes more sense to handle data correction using dedicated migration scripts or temporary migration modules, rather than relying on the patch mechanism.

This clarification was very helpful. Thank you for sharing your experience.

27 Jan

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.

See the full guidelines