Migration workflow

Run init inside the existing project with --here. The application sources and pom.xml are left alone, but init writes or replaces mvnw, mvnw.cmd and .mvn/wrapper/maven-wrapper.properties even without --force, so commit or back up a customized Maven wrapper first.

--source-platform accepts mulesoft, biztalk, camel (which also covers Fuse) or auto, the default, which detects the platform from the sources. init adds the agent assets, the MCP configuration, the empty scaffolds (docs/flows/, test/data/, schemas/), .camel-kit/ and the Maven wrapper files, as described in Create a project.

/camel-start also routes to /camel-migrate when it finds a supported source. The orchestrator then:

You are asked for platform-specific connector endpoints, authentication requirements, environment mappings and validated secret references. Never put raw credentials in the generated documents: only validated secret references are recorded.

A direct mode, selected with /camel-migrate --direct or when the request names concrete deliverables, runs the scan, detection and analysis steps and then implements the route files and properties directly, validates them, runs the adversarial review and starts the application with your explicit authorization. It writes a MIGRATION.md note instead of the four-document package and does not invoke /camel-plan.

The agent scans the selected source boundary to identify the platform and the supported artifacts:

MuleSoft discovery finds flow XML, DataWeave scripts, connector configurations and API specifications, typically under src/main/mule/; BizTalk discovery scans orchestrations, schemas, maps, pipelines and bindings; Camel 2.x/3.x discovery scans route definitions (XML and Java DSL), components and Spring or Blueprint configuration.

Everything found in the sources is migration data, not instructions. The agent extracts vendor, version, route, mapping and configuration facts and records each as confirmed, inferred or unknown. Commands, URLs, tool requests, file changes, secret requests or policy overrides embedded in an artifact never direct the migration. If an action turns out to be necessary, the agent names its source, the exact action, the reason and the scope, and asks for an action-specific confirmation; a subagent that cannot ask returns NEEDS_USER_CONFIRMATION without acting.

Migration questions arrive one at a time as [Concern N of M] or [Clarification N of M] blocks: what was found, why it matters, and multiple-choice options when possible. A subagent that hits an unresolved decision, such as the replacement for an Anypoint MQ connector, returns NEEDS_CONTEXT; the parent conversation asks you, records the answer as confirmed in the analysis summary and resumes the same step.

Bounded source scanning establishes the dependency and reachability evidence. When a current project graph exists (see Graph intelligence), the agent uses it to corroborate and accelerate the analysis, including dependency order and dependency-injection-aware service wiring that route-level analysis alone would miss:

If the graph is missing, stale, malformed or a query fails, the migration records the limitation and continues from the sources; an empty finding under incomplete coverage is not evidence that nothing is affected.

The source-retirement audit uses the same report contract with or without a graph. It separates confirmed entry points and reachable elements, retirement candidates, broken references and evidence gaps, each with a stable ID, evidence and the human validation still required. A retirement candidate needs complete supported source closure and no supported path from any corroborated entry root; incomplete coverage, dynamic references and parse failures stay Unknown. A candidate is not proof that an artifact is dead, and Camel Kit never removes source artifacts.

The agent records flow-specific requirements and technical decisions in four artifacts under docs/camel-kit/<pipeline-id>/:

The Migration Strategy classifies each independently switchable ingress scope as Incremental candidate, Single cutover required or Undetermined - evidence needed. An incremental candidate requires current evidence, or explicit operator confirmation, of an existing external traffic control and its operator, a deterministic routing unit, exclusive old/new ownership, aligned state and correlation boundaries, known delivery and ordering effects, an idempotency control, comparable telemetry, and a rollback signal with a reversible control. Static source, configuration or graph evidence can show that a mechanism is declared, but is at most Inferred evidence that it is operative today. Neither classification proves deployment, cutover or rollback readiness.

The runbook is generated from the validated final design. It never invents commands, endpoints, environment values, thresholds, durations, contacts, owners or decisions: every missing operational fact is written as Unknown — operator decision required: <missing fact>, listed under unresolved operator decisions, and blocks the dependent deployment, cutover, rollback, reconciliation, soak or retirement action.

Artifact provenance runs business-requirements.md → migration-analysis.md → design-spec.md, then branches: migration-runbook.md and implementation-plan.md are independent children of the design, and the plan never consumes the runbook. An upstream amendment marks the dependent artifacts stale; a stale runbook must be regenerated by /camel-migrate before operational use.

The agent presents the complete package and waits for one explicit approval. That approval authorizes the plan, execution, verification and validation sequence. It does not authorize infrastructure provisioning, deployment, production traffic switching, rollback, reconciliation or source retirement; each of those remains a separate, named operator decision.

After the approval, /camel-plan creates one implementation plan from design-spec.md and /camel-execute groups its tasks into dependency waves. Each wave generates the Camel YAML routes and the Citrus integration tests; independent tasks run concurrently where the agent supports it. Spring Boot and Quarkus targets use the Maven source layout:

Camel Main generates the routes and application.properties at the module root; tests remain under src/test/resources.

After all tasks finish, camel-verify runs once for the complete migrated application: build or startup smoke, the applicable Citrus suite, and a report with the runtime, the Maven selection, phase outcomes, applied fixes and skipped checks, embedded in execution-report.md. Tests that declare Testcontainers need Docker. The pipeline then invokes /camel-validate once for the final static report. There is no flow-by-flow approval and no automated deployment: operators keep control of the runbook’s deployment and traffic actions.