Migrating Legacy CRUD Applications to QQQ 4.0
Preserve data and contracts while replacing one workflow at a time.
Updated for the QQQ 4.0 release review on September 10, 2026.
Record the existing behavior
Identify schema, validation, authorization, API clients, scheduled work, and external side effects. Pick a bounded workflow and save representative success and failure cases as tests.
Map the data explicitly
Use table and field backend names to map an existing schema. QQQ metadata does not automatically migrate the database or reproduce undocumented application rules. Review generated or handwritten metadata and validate the complete QInstance.
Migrate without changing every contract
Keep existing APIs where clients depend on them. Configure new application API metadata deliberately and compare behavior. Reuse Java services from process steps when appropriate; shared runtime language does not automatically share transactions or authentication.
Reconcile persisted records, denied access, errors, and side effects in staging. Maintain an application/data rollback procedure. See legacy migration and the 4.0 API migration checklist.
