Changing the database under a Flowable deployment

Larger history tables increase the time and risk of the data copy, because every historic activity, variable and job row has to be moved, verified and indexed on the target. The history tables are optional in Flowable, so the first question is whether your organization needs all of that history carried over or only the history required for open cases and audit. Reducing the volume you copy, archiving closed instances to a separate store, or agreeing a retention cut-off before the work starts all shorten the copy and the verification. Ask for the row counts per table as part of the written scope.

Yes. The number of deployed process and case definitions, and the number of instances still running at cutover, determine how much data must be copied consistently and how many cases the team must test. A small set of definitions with a few hundred open instances is a simpler copy than many versions with active instances spread across them. Reduce the effort by retiring unused definitions, completing or drainning instances before the window, and confirming which definition versions must remain available. Ask the partner to list the definitions and instance counts per state in the scope.

Custom tables, triggers, views and raw SQL in your delegates, listeners or reporting queries are outside the vendor scripts, so each one needs a separate translation, copy rule and test. Effort rises with the number of custom objects and with how tightly they depend on one database's behavior. To reduce it, move raw SQL behind the engine API where practical, document every custom object before the work starts, and decide which ones move unchanged. Your own team can often produce this inventory, which shortens the discovery phase.

Queries that depend on vendor features such as proprietary date functions, locking hints, sequences, case sensitivity rules, or string and paging syntax need rewriting and retesting on the target. The Flowable engine handles its own tables through the supplied scripts, so the risk sits mainly in your code and reports. Reduce the work by listing every native query, using standard SQL where you can, and checking the MySQL precision note in the Flowable configuration docs if MySQL is one of the sources. Ask for a dialect review as a separate line in the quote.

More Flowable nodes sharing one database mean more coordination during the switch, because every node must stop, point to the new database and restart in the right order. The async executor uses lock owners and lock expiration times stored in the database, so timers and jobs in flight must be drained or safely handed over. Many timers due during the window raise the risk of duplicate or missed firings. To reduce the effort, plan a quiet period, pause new job creation where your design allows, and confirm the node count and timer schedule before the window is set.

A shorter cutover window needs more preparation, rehearsal and automation, and often a replication-based approach, while a longer window allows a simpler stop-copy-start sequence. PostgreSQL documents logical replication between major versions as a way to reduce downtime to several seconds, but that path needs careful setup and monitoring. Your business calendar, change freeze periods and the number of dependent systems set the acceptable window. Ask for the window you need in writing and whether the quote includes rehearsals against a copy of production.

Verification depth is the largest variable after scope. A check of row counts and schema objects is quick, while confirming that running instances continue correctly, that timers fire once, and that reports return the same results requires scripted tests and business sign-off. Compliance-driven environments often need evidence retained for the change record. Reduce the effort by agreeing acceptance criteria and test cases up front. DeployOpen prepares the controls and evidence, but independent auditors and certification bodies decide whether your controls meet a requirement. The quote follows from a written scope that names each verification step.

Yes, in most cases the change is a database move rather than a new application, but it is not a configuration toggle. Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and the engine tables must be created in the target database from the vendor-specific scripts before any data moves. The application then points at the new JDBC connection, and the data copy and cutover decide whether the move is clean. Confirm the exact Flowable version you run, because the scripts and supported combinations are tied to that version.

The cutover window depends on how much data the engine holds, how many jobs and timers are in flight, and how much downtime your business accepts. Flowable itself does not publish a duration for this work, so treat any number from a vendor or partner as a claim to test against your own copy. Ask for a rehearsal on a production-sized copy and measure the copy and reconciliation steps. Your window must also cover pausing the async executor so no job runs against a half-copied database.

Cost follows the work, not the database name. The main drivers are the number of Flowable engines and schemas, whether history tables are kept, data volume, the number of custom delegates and SQL queries that assume the old vendor's dialect, the number of environments to rehearse in, and how strict the cutover window is. Some costs are one-time, such as design, rehearsal and cutover support. Others recur if you keep a parallel environment or need ongoing database operations after go-live. Ask any partner to split the quote into those groups.

Often yes, if they have done schema migrations and can test Flowable's behavior. Flowable notes that production DDL is often run only by database administrators, so your DBA will likely execute the create scripts. The harder parts are the data copy, checking that timestamps and identifiers survive the move, verifying the async executor's lock handling, and proving that counts and in-flight work match before and after. Decide early who owns each step and who signs off on the cutover.

No. Flowable's in-place migration path for Camunda 7 and Activiti data addresses moving those engines' active instances and history into Flowable. It does not change the database vendor under a running Flowable deployment. If you are on Camunda or Activiti and also changing databases, plan the two moves as separate steps with their own testing, and confirm the sequence with your engineers before you commit to a window.

The async executor keeps lock owners and lock expiration times in the database, so the nodes that run jobs depend on the same tables you are moving. If nodes keep running during the copy, jobs can execute against partial data or be locked against the old database. Plan to stop all engine nodes, or drain them, before the final copy, confirm no locks are held, and then start the new nodes against the target. Check that timers scheduled for the cutover window fire once and only once after the restart.

Ask for a written scope that names the Flowable version, the source and target databases and versions, the engines and schemas in scope, whether history tables move, and the environments to rehearse in. Ask how the data copy will be verified, how in-flight jobs and timers will be handled, the rollback plan and its time limit, and what is delivered at each step. Ask who runs the production cutover and who is on call afterward. Compare quotes on those items, not on a headline figure.

Pick a target version that your vendor and your Flowable version both support, and that is still in its support window when you go live. For PostgreSQL, the versioning policy lists the supported majors and their end dates, so check the current table before you choose. Also confirm that your Flowable release and JDBC driver support the target version, because support is set by the combination you run.