Bizagi vs Flowable: when each option fits
Most readers arrive here because a Bizagi renewal is due, the on-premises license is no longer available to buy, or a data residency rule means the cloud PaaS cannot hold the process data. Bizagi fits teams that want low-code modeling and a delivered work portal in the cloud, with the vendor operating the platform. Flowable fits teams with Java or Spring developers who must run the engine on their own servers or in an air-gapped network. The choice turns on three questions: where the process data must physically live, how much user interface work your organization is prepared to build, and who will operate the platform after go-live.
Start with data location, because it usually decides the question before features do. If regulators, customer contracts or internal policy require process data, forms and attachments to stay inside your own accounts or data centers, a cloud PaaS is unlikely to qualify without a legal and security review. Flowable runs as an embedded library in your application or as a standalone service over REST, and it supports several relational databases, including PostgreSQL, Oracle and Microsoft SQL Server. Confirm with your security team which database and hosting pattern your policies accept, and ask Flowable or a partner to confirm which commercial features, if any, you would need in that environment.
Then assess the interface work honestly. Bizagi includes the modeling, forms and work portal in one product, so business analysts can deliver a usable task interface quickly. Flowable's open-source engines provide the BPMN, CMMN and DMN execution, but the community edition does not include the UI applications, so your developers build task lists, forms and monitoring. Ask who will own that build and who will maintain it after each upgrade. Flowable 8.0.0 was released on February 27, 2026, and it moved to Spring Framework 7 and Spring Boot 4, with no backward compatibility for Spring Boot 3, so plan for that upgrade path when you estimate the engineering work.
Which option fits which scenario
This table pairs common Bizagi-driven scenarios with the option that usually fits better and the condition that decides it. Read each row against your own constraints: where processes must run, who builds them, and whether business users or developers will own the models. The main takeaway is that Bizagi's strength is business-led, visual, low-code delivery in its cloud PaaS, while Flowable is a code-first engine that you host and build around.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Cloud PaaS is acceptable and business analysts model processes | Stay on Bizagi | Your data residency rules allow the cloud service and business users need visual modeling without developer involvement |
| On-premises or air-gapped requirement | Flowable | Processes, data and the engine must run inside your own network, and you accept building the front end and forms yourself |
| Developer-led team with existing Java skills | Flowable | Engineers will own process logic, APIs and deployment in Spring or servlet applications, and CI/CD can version BPMN and DMN files |
| Need for a ready work portal with forms and task inbox | Stay on Bizagi or evaluate CIB seven | Your users need a task interface quickly, since Flowable's open-source edition does not include the commercial work portal and form tooling |
| Team wants to keep existing Bizagi diagrams | Flowable after BPMN export review | Your diagrams are mostly standard BPMN 2.0 and you can re-add extended attributes, rules and forms the export drops |
| Vendor lock-in and licensing predictability are the main concern | Flowable | You want Apache-2.0 engines you can inspect and host, and you can budget for in-house or partner engineering time |
| Commercial low-code editions and vendor support are required | Flowable commercial editions or Bizagi | Your governance needs visual debugging, security controls and vendor SLAs, which Flowable sells separately from its open-source engines |
Where Bizagi's low-code model saves effort
Bizagi's main advantage is that it packages process modeling, forms and a work portal into one managed product, and the vendor operates the cloud environment underneath. A business analyst can model a process, adjust a form or change a routing rule without opening a development ticket, which is the effort Bizagi removes for teams that accept its cloud PaaS model. The researched facts for this comparison do not describe the current modeler, form designer or portal in detail, so confirm with Bizagi exactly which modeling notations, form controls, user roles and portal features are included in your subscription tier before you weigh them against Flowable.
That advantage only matters under specific conditions. If your organization has already decided that process data may sit in a vendor-operated cloud, and business users need to change processes often without waiting for a release cycle, a managed low-code environment removes a large share of day-to-day work from your developers. If either condition does not hold, the saving disappears, because Flowable's engines are Apache-2.0 licensed and run in your own infrastructure, and the modeling, forms and portal work moves to your team or a partner. Flowable's open-source edition provides the BPMN, CMMN and DMN engines and their REST APIs, while the commercial Flowable Work, Engage, Orchestrate and Design products add the low-code modeling layer, as described on the Flowable open source page.
Before deciding, run a short test with a real process your analysts maintain today. Ask Bizagi to demonstrate, on a trial or sandbox, how a business user publishes a change, who approves it, and how the change is versioned and rolled back. Then write down what the equivalent change would require on Flowable: a model edit in a tool your team chooses, a form built by a developer, and a deployment through your own pipeline. Comparing those two change paths, with named roles and hours counted by your own staff, will show whether the low-code saving is worth the cloud dependency for your processes.
Capabilities side by side: Bizagi and Flowable
This table compares how Bizagi and Flowable cover modeling, case and decision logic, forms, task work, monitoring, identity, hosting and licensing. Bizagi cells name what to confirm with the vendor, so check them against your requirements before you decide. Flowable cells describe the open-source engines, where most user-facing work falls to your developers.
| Capability | Bizagi | Flowable (open source) |
|---|---|---|
| Process modeling (BPMN 2.0) | Processes are modeled in Bizagi Modeler and Studio; confirm BPMN 2.0 execution coverage with Bizagi. | BPMN process execution engine under Apache 2.0, with Java and REST APIs. |
| Case management and decision rules (CMMN, DMN) | Confirm with Bizagi whether case management and decision rules are native or add-on features in your plan. | Separate CMMN case engine and DMN decision engine, both included in the open-source engines. |
| Forms and data model | Forms and data model are built in the platform; confirm form designer scope and export options. | Version 7.0.0 removed the UI applications and form engine, so your developers build forms and data screens. |
| Work portal or task interface | Bizagi provides a work portal for users; confirm task list features and customization with Bizagi. | No end-user task portal in the open-source edition; build one on the REST APIs or evaluate commercial editions. |
| Low-code modeling and debugging | Low-code modeling is Bizagi's core offering; confirm which modeling features your subscription includes. | Low-code modeling and visual debugging come with commercial editions such as Flowable Design and Orchestrate, not the open-source engines. |
| Monitoring | Confirm process monitoring and reporting available in the cloud PaaS with the vendor. | Spring Boot actuator endpoint at /actuator/flowable for running processes; wider governance dashboards are commercial. |
| Identity integration | Confirm supported directory and single sign-on options for the cloud PaaS with Bizagi. | Identity service can be replaced by implementing the interface; an LDAP reference implementation is provided. |
| Hosting options | Cloud PaaS only for new licenses since 2022; confirm data location options in writing. | Embedded JAR in Java applications or standalone REST service; supports H2, MySQL, Oracle, PostgreSQL, DB2 and SQL Server. |
| Licensing | Cloud subscription; confirm terms, data ownership and exit rights in the contract. | Apache 2.0 engines at no license fee; commercial editions and professional services are sold separately. |
What Flowable's open-source edition leaves to your developers
Flowable's open-source engines execute BPMN, CMMN and DMN models but ship without the front-end, task portal and operations tooling that Bizagi includes out of the box. The cards below cover the components your team designs, builds and runs, and the conditions that make each one small or large.
Forms and user interface
Flowable's open-source engines do not include a form builder or end-user interface, so every human task needs a screen built by your team. If you already run a front-end team with a component library, the work is mostly wiring forms to task variables. If your processes have many branching forms, file uploads and conditional fields, expect this to be the largest rebuild item. Ask Flowable which UI components its commercial editions provide before you commit to a design.
Work portal and task lists
Bizagi gives business users a work portal with task inboxes and case views. With Flowable's open-source edition, you build the task list, filtering, claiming and delegation logic yourself, using the REST APIs or Java APIs. A simple approval flow with one queue per team is a small build. Multi-role queues, escalations and reassignment across many departments make this a substantial product effort.
Identity integration
Flowable's docs describe replacing the identity service by overriding the default implementation or implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Your team maps users, groups and roles from your directory into candidate groups and assignees. If your directory is LDAP or Active Directory and roles are simple, the reference implementation is a starting point. Custom roles, delegated authority or synchronization from several sources need more design and testing.
Monitoring and operations
The Flowable Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes. Your operations team connects this to its metrics, alerting and dashboards, and decides what counts as a stuck instance. Teams with an existing Spring Boot monitoring stack will find this a modest integration. Teams without one should plan for dashboards and runbooks as a separate piece of work.
Business rule authoring
DMN decision tables run in Flowable's open-source engine, but authoring and maintaining them is a process your team must own. Bizagi users are used to editing rules in the modeling environment. With Flowable, rules are DMN files kept in version control, edited by developers or by analysts through a tool your team chooses. Small rule sets with clear owners are manageable. Large rule sets used by several processes need a governance process for changes and testing.
Data model and case data design
Bizagi stores process data in a data model you define in its tooling. Flowable stores process variables and its own engine tables, and your application decides how business records are structured in your own database. Designing that schema, its migrations and its access rules is developer work. Teams with an existing system of record can keep the business data where it is. Teams starting from scratch should expect this design work to take as long as the process models.
Cloud PaaS or self-hosted Flowable: which operating model fits
Bizagi's cloud PaaS is the operating model closest to what most Bizagi users have today. The vendor runs the environment, applies platform updates and handles the infrastructure underneath your processes. Your team still owns the models, forms, business rules and data design, and it depends on the vendor's upgrade calendar. Moving to self-hosted Flowable changes that split, so the first question is what you would take on.
- Patching: Under a PaaS, the vendor patches the runtime. Under self-hosted Flowable, your team patches the JVM, the application server or Spring stack, the database and the operating system.
- Backup and scaling: A PaaS usually includes backup and capacity management in the subscription. Self-hosting means you design database backups, restore tests and node scaling yourself.
- Upgrade path: Flowable 8.0.0 was released on February 27, 2026, and moved to Spring Framework 7 and Spring Boot 4 with no backward compatibility for Spring Boot 3. Any Flowable application on Spring Boot 3 needs planned code and dependency work before that upgrade.
- Vendor-side work: Confirm with Bizagi which upgrade and support obligations stay with them, and which ones pass to your team if you later self-host.
What to check: ask Bizagi in writing which environments, backups, patch cycles and recovery objectives are included in your subscription.
Self-hosting Flowable in your own cloud account or data center gives you control over hosting location, network paths and upgrade timing. Flowable runs embedded in a Spring application or as a standalone service with REST APIs, so the platform team and the application team share the operational load. Responsibilities are explicit, and they are yours to staff.
- Clustering: The async executor runs timers and asynchronous jobs from a thread pool and coordinates multiple nodes through lock owners and lock expiration times stored in the database. Expired locks are recovered, so another node picks up the work. Test failover against your real database, not only a single node.
- Monitoring: Spring Boot starters expose an actuator endpoint at
/actuator/flowablefor monitoring running processes. Wire it into your existing observability stack. - Identity: Flowable's identity management can be replaced by implementing the IdmIdentityService interface, with an LDAP reference implementation provided. Plan this integration early.
- Upgrades: Schedule the Spring Boot 4 move as a project, with regression tests on your BPMN, CMMN and DMN models before any production change.
What to check: confirm which database engines your standards allow, since Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server, and confirm how your team will run the upgrade calendar.
Organizations that cannot send process data or depend on a vendor's cloud use a self-hosted engine inside a restricted network. Flowable is Java-based and runs without a vendor connection, so the platform can operate on-premises or in an isolated segment. The trade-off is that every artifact must be sourced, stored and tested inside that boundary.
- Patching and artifacts: Your team maintains the mirror of the Flowable libraries, the base images, the JDK and the database engine. Each update passes through your internal change process.
- Backup and recovery: Backups stay inside the boundary. Test restores on a schedule and document recovery steps for process instances that are in flight.
- Scaling: Capacity depends on hardware you provision. Plan node counts and database sizing before the load arrives, because there is no elastic cloud to absorb a spike.
- Support and upgrades: Commercial Flowable editions add professional services and partners, while the open-source edition relies on the community forum. Confirm which support model satisfies your risk policy before you commit.
What to check: confirm with your security and compliance owners how air-gapped updates, vulnerability tracking and evidence of change control will be produced for the upgrade to Flowable 8.0.0.
Data location, identity and compliance implications
Moving from Bizagi's cloud PaaS to self-hosted Flowable changes where process data, attachments and audit history live, and who is responsible for proving it. The cards below cover the components that carry that responsibility, from the database and identity layer to the evidence an assessor will request.
Process data and attachments
With Flowable running in your environment, process variables, task history and job tables sit in the database you provision, but uploaded documents and form attachments are not stored by the engine itself. Flowable's open-source edition does not include the form and content engines, so you must decide where files live, such as an object store or document system in your own infrastructure. Confirm with Bizagi where its cloud PaaS stores attachments and in which regions, since that is the baseline you must match or improve.
Audit history and retention
Flowable records process history through its history tables, and you control how long they are kept and whether they are purged. Retention, archival and deletion are configuration and operational decisions that your team owns rather than a vendor default. Map each regulatory retention period to a history cleanup job and test that restores return the same audit trail you would present to an assessor.
Supported databases
Flowable supports H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server. H2 is suited to development and testing, not production. MySQL versions below 5.6.4 lack millisecond precision, which can affect timestamps in audit records, so verify your version before choosing it. Pick the database your organization already operates, backed up and monitored to the same standard as other regulated systems.
Identity and single sign-on
Flowable does not ship a full identity provider for production use. Its identity management can be replaced by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference. Plan how users, groups and roles from your directory map to Flowable's identity model, and how single sign-on is enforced at the application or gateway layer. Bizagi's identity integration should be documented first so you know which features need rebuilding.
Logging and access control
Access control in a self-hosted Flowable deployment is split between the application, its REST APIs and the network in front of them. Engine logs, API access logs and database audit logs must be collected centrally and protected against tampering. Document who may deploy process definitions, read instance data and change runtime state, because these permissions are not inherited from a Bizagi tenant model automatically.
Compliance evidence to produce
Flowable does not certify your environment, and DeployOpen prepares systems, controls and evidence for compliance assessments without issuing audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Expect to produce architecture diagrams, access reviews, backup and restore records, change logs for process definitions and your data retention rules. Confirm Bizagi's current data residency commitments and certification status directly with Bizagi, because your gap analysis depends on them.
What drives the cost of each option
The Bizagi side of the cost is a recurring subscription to its cloud PaaS, billed as an ongoing fee for the platform, its modeling and runtime environments and the vendor's hosting. Ask Bizagi to state in writing what the subscription includes, how many users, processes or environments it covers, which environments (development, test, production) are separate line items, what happens to pricing at renewal, and how data export is handled at exit. Flowable's open-source engines carry no license fee under Apache-2.0, so the cost sits in hosting, database operations, developer time and any support you buy. If you choose a Flowable commercial edition, request its price, the modules included, and the support tier as separate items in the quote, since its commercial products add low-code modeling and governance on top of the same engines.
On the Flowable side, the one-time costs are the largest. Expect developer time to rebuild forms, the work portal and integrations that Bizagi provides out of the box, plus the data model and business rules, which the BPMN export does not carry over. Flowable 7.0.0 removed the UI applications and the form and content engines, so the task interface and forms must come from your own applications or a separate product. Recurring costs include database and application hosting, monitoring, the upgrades that major versions require (Flowable 8.0.0 moved to Spring Boot 4 with no backward compatibility for Spring Boot 3, for example) and the engineers who keep the engine running. Budget for a team able to maintain Java, Spring and the async executor's lock handling in the database, and confirm that skill set internally before you commit.
When you request a quote from an implementation partner, including DeployOpen, ask for a fixed scope listing each deliverable separately: process migration, form and portal rebuild, integrations, identity connection, hardening, backup, documentation, training and post-go-live support. Ask whether ongoing upgrades and monitoring are a retainer or a per-incident charge, and who owns the code and configuration at the end. Ask Bizagi and Flowable to confirm in writing which support terms, renewal conditions and exit assistance apply to your contract. Finally, ask your own team to estimate the parallel run period, since running old and new processes side by side adds cost on both platforms until open cases close.
How a move from Bizagi to Flowable unfolds
The sequence turns a Bizagi estate into a self-hosted Flowable deployment in which every process, form and rule is accounted for, running processes finish on the old platform, and the new platform takes over only after its cases are verified.
Inventory processes, forms, rules and data
Your business analysts and process owners list every Bizagi process in use, along with its forms, business rules, data entities, users, roles, integrations and reports. Bizagi administrators confirm which processes are live and which are retired. The output is a signed inventory that marks each item as migrate, rebuild, retire or keep on Bizagi during transition. The step is complete when each process owner has signed off on their section and no live process is unassigned. The sibling page on exporting processes from Bizagi covers what the export keeps and drops in detail.
Export BPMN 2.0 diagrams and record lost attributes
Export the diagrams you marked for migration as BPMN 2.0 XML from Bizagi and open each file in a BPMN modeler. Compare every exported element against the Bizagi original and record the extended attributes, form bindings, rule references and custom properties that the export may drop. Your developers keep this record as the rebuild list for the next steps. The step is complete when every diagram has a written list of lost or unverified attributes that a named owner has reviewed. The sibling page on migrating from Bizagi to Flowable covers the export mechanics.
Build the engine and interface layer
Your platform engineers deploy Flowable in your own infrastructure, choosing an embedded Spring application or the REST application, a supported database and an identity source. Because Flowable's open-source edition does not include a work portal, your developers build or adopt the task interface, user management and monitoring that Bizagi's built-in portal provided. Security reviewers confirm authentication, network placement and backup for the new stack. The step is complete when a test process runs end to end on the target environment, tasks appear in the interface for test users, and the team has a tested backup and restore procedure.
Rebuild forms, business rules and the data model
Developers recreate each Bizagi form as a front-end component, rebuild each business rule as DMN decision tables or code, and map the Bizagi data model to database tables or service APIs in the Flowable application. Process owners test each rebuilt form and rule against the examples from the inventory, comparing outputs with the Bizagi results. The step is complete when every migrated process has a test suite whose expected outcomes match the original Bizagi behavior, and the owners have approved the differences that remain. Because this work is largely custom, it is usually the longest part of the project.
Run old and new processes side by side
New cases start on Flowable for the processes that have passed testing, while cases already open in Bizagi finish there. Operations staff monitor both platforms, compare queue volumes, error rates and task completion times, and log any defect in a shared tracker. Users receive guidance on which system holds each case. The step is complete when no open case remains in Bizagi for the migrated processes, or when the owners have agreed on a documented exception for each case that must stay. Your Bizagi licensing contract should be reviewed during this period so that the cloud subscription continues as long as any case depends on it.
Cut over and decommission Bizagi
Once the parallel run shows stable results, you switch all new intake to Flowable, lock the Bizagi processes against new cases, and archive the final process data, audit logs and reports that your retention rules require. Access to Bizagi is removed for users who no longer need it, and the subscription is ended according to the terms in your contract. The step is complete when Bizagi holds no active cases, the archive has been verified, the access list has been revoked, and the cancellation has been confirmed in writing by the vendor. Ask your compliance lead to confirm which retention and evidence requirements apply before archiving begins.
Questions buyers ask before moving from Bizagi
How much developer effort does Flowable need for forms and a work portal?
Flowable's open-source edition gives you the BPMN, CMMN and DMN engines and their REST APIs, but it does not ship the user interface layer that Bizagi provides out of the box. Flowable 7.0.0 removed the UI applications and the form and content engines from the project, so forms, task lists, dashboards and any work portal are built by your developers in an application of your choice. Effort depends on how many forms you have, how much validation and document handling they need, and how many roles see each screen. Ask any partner to size the forms inventory from your current Bizagi case types before estimating build work. Flowable's commercial products, including Flowable Work, add low-code modeling and a work interface, but that is a separate licensing and cost decision.
Can our team migrate from Bizagi without outside help?
Yes, if your team has Java developers who can run a Spring Boot or servlet application, operate a relational database and write REST integrations. Flowable is code-first, so the skills you need are engineering skills rather than modeling skills alone. Teams without that experience usually need outside help for the engine setup, the identity integration, the form rebuild and the parallel run. Flowable's docs describe identity management as replaceable through an interface, with an LDAP reference implementation, so an engineer must connect your directory. Assess your internal capacity against those tasks before deciding.
How long does a Bizagi to Flowable migration take, and what drives it?
No duration can be stated from the sources available here, so treat any figure in a proposal as something to verify. The main drivers are the number of processes and case types, the number and complexity of forms, the business rules that must move into DMN decision tables, the volume of open cases that must finish in Bizagi, and the integrations that call external systems. Running old and new processes side by side until open cases close is often the longest phase, because it depends on how long your longest case takes to finish. Ask for the timeline to be tied to a written, phase-by-phase scope.
What does ongoing support look like for an open-source engine compared with a subscription?
With Bizagi's cloud subscription, the vendor operates the platform and provides support under its contract. With Flowable's open-source edition, the engine is Apache-2.0 licensed and free to use, but support comes from your own engineers, the community forum, or paid professional services and partners that Flowable offers separately. Your recurring costs therefore shift to hosting, patching, monitoring and the staff who maintain the forms and integrations. Flowable's commercial editions are an option if you want vendor support on the same engines. Ask any provider which parts of support are included in the price and which are billed by the hour or as a retainer.
Do Flowable 8 upgrades need special attention?
Yes. Flowable 8.0.0, released on February 27, 2026, upgraded to Spring Framework 7 and Spring Boot 4, and its release notes state there is no backward compatibility for Spring Boot 3. Flowable 8 also makes Jackson 3 the default JSON library, with a Jackson 2 compatibility layer, and removes JUnit 3 and 4 support. If your custom code, tests or integrations depend on Spring Boot 3 or Jackson 2 behavior, plan that work before you adopt Flowable 8. Flowable 7.0.0 had already moved the project to Java 17, Spring Boot 3 and Jakarta EE, so check your Java and framework baseline against both release notes.
Do our BPMN diagrams carry over to Flowable?
BPMN 2.0 diagrams can usually be imported because Flowable executes standard BPMN, but the exported XML does not carry everything Bizagi uses. Bizagi-specific extended attributes, forms, data model bindings and business rules may be dropped or need to be rebuilt in Flowable constructs. Standard process flow, gateways and service tasks are the easiest part to move. Run a sample of your most complex diagrams through Flowable's engine early, and compare each one against the original behavior before committing to a full export. A written inventory of extended attributes is the most useful first deliverable.
What should we ask an implementation partner for in a written scope?
Ask for a scope that names each process and case type to move, the forms and screens to rebuild, the decision rules to convert to DMN, the integrations to re-create, and the identity and database setup. Require a list of what is excluded, such as open-case handling, training or hosting. Ask how the parallel run will be managed, how cutover and rollback work, and what evidence will be handed over for your security and compliance reviews. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner to confirm which of these items it will deliver and which your team must own.
How DeployOpen helps you evaluate or move from Bizagi
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Bizagi vs Flowable, we start by agreeing on which Bizagi processes, forms and rules are in scope, then decide with you whether a code-first Flowable deployment or another engine fits your team.
How we scope
- We inventory the Bizagi processes, forms, business rules and integrations you want to evaluate or move, in writing before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, so you know what a Flowable proof of concept covers.
- We confirm which Flowable edition, database and hosting model fit your environment, including whether your developers can own a code-first engine.
How we build
- We plan the Flowable deployment in your cloud account, data center or air-gapped network, including the database and identity source you choose.
- We rebuild the task interface, forms and data model that Bizagi provided, since the open-source engine does not supply a work portal of its own.
- We test BPMN, CMMN and DMN models against representative cases, including timers and async jobs running across multiple nodes.
How we hand over
- You receive the written documentation of models, forms, rules, configuration and the data you exported from Bizagi by hand.
- We run old and new processes side by side for an agreed period, so open Bizagi cases can close without disruption.
- We train your developers and administrators on deploying, monitoring and upgrading the engine you will operate.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering Flowable version changes such as major framework updates.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors and certification bodies issue any reports.
- Ask us to confirm backup, restore and upgrade procedures for your environment before the cutover, and again after each release.
