Moving automation platforms without losing the business process

An automation migration becomes dangerous when a team copies the diagram and overlooks unfinished obligations. Running workflows, pending callbacks and encrypted credentials remain real after an endpoint changes. The new platform must either continue that work or leave the old executor a clearly bounded responsibility.

Four October publications help frame that choice. They concern different products and workloads, so their value here is a migration analysis, not a recipe claiming that the products integrate with one another.

What the publications expose

A Fairwinds member post published by CNCF on October 16 describes moving n8n between Helm charts while preserving persistent components. It is the author’s operating experience, not a requirement for every installation.

Workato’s October 14 Red Hat and Lenovo discussion considers build-or-buy choices. GitLab’s October 13 announcement introduces orchestration across development handoffs. Azure’s October 8 Hosted Skills publication separates DAG planning from durable execution.

A diagram can describe work without containing everything needed to resume it. The plan, execution history, business records and credentials may live in different places. Those dependencies determine migration effort.

Choose the unit of migration

A new workflow definition, an existing execution and the whole service are different migration units. A new definition can handle future requests while being unable to interpret an older history. An existing execution may await a callback sent to the previous endpoint. A service move also affects encryption keys, schedules and external senders.

Inventory active obligations before choosing a cutover method. Which requests have been accepted? Where is their authoritative result? Who sends the next event? Is that event safe to repeat? What would be needed to start the old system again?

One possible boundary sends new requests to the new executor and lets old executions finish where they started. That temporarily costs two environments, but avoids translating every history. An immediate move may be justified by security or maintenance constraints; it requires stronger evidence that unfinished work remains interpretable.

There is also an organizational boundary. A business team may own approval rules while a platform team owns the runtime. Migration changes both teams’ ability to intervene. The cutover plan should say who can pause intake, reconcile an uncertain result and decide to resume, rather than distributing those decisions across several chat channels.

A hypothetical service-request cutover

Consider a CRM that sends requests into automation. The workflow checks documents, waits for employee approval and creates a task in an operational system. The company changes how the executor is deployed. This is a design example, not a claimed customer delivery.

At cutover, one request is waiting for a person. Another already submitted a task but lost the acknowledgement. Restarting both from the beginning risks duplicate work. Turning off the old endpoint can also strand an approval.

For the waiting request, preserve the link between the decision and the document version it authorizes. For the uncertain submission, retain its operation identifier and check the destination result. Route incoming events using request identity, not merely the currently active service address. Each execution needs one owner throughout the transition.

Rehearse with synthetic requests in those same waiting states. Check a late callback, a repeated webhook and access to a previously stored file. Starting a container proves none of those outcomes. Verify separately that the restored executor can obtain the right credentials and decrypt the records it must use.

The rollback condition should be measurable. If callbacks cannot reach a known waiting request or an accepted operation cannot be reconciled, stop new intake or return it to the agreed path. “The new environment looks healthy” is too broad to authorize continued business processing.

Price responsibility, not just hosting

Self-hosting offers environmental control while leaving state management, upgrades and recovery with the team. A managed service can absorb some duties, with remaining dependencies on contracts and data portability. These publications do not establish a universal build-or-buy answer.

During evaluation, ask to see an external action that has started but lost its response. Where does an operator inspect it? What can be exported? What happens after the workflow schema changes? Those answers reveal more about portability than the number of available blocks.

Reliable document, CRM and task workflows develops the business boundaries. The AmoCRM project adds related communications context. A workflow automation plan should include the cutover and the rules for completing existing executions.