LambOGenius Integration Migration

Overview

A staged migration workflow with persisted evidence.

LambOGenius Integration Migration analyzes existing integration assets, generates source-flow evidence, plans an Azure target, creates a migration candidate, validates generated artifacts, and prepares a deployment package, and estimates monthly Azure running costs before deployment approval. Each stage writes inspectable outputs so a run can be reviewed, resumed, or gated in CI.

Full batch runs report input, output, total model tokens, and call counts when each executed stage finishes or fails. See sample notifications and single-stage limitations. The Azure cost estimate is separate from AI model usage and license metering.

Requirements

Install the toolchain used by your migration stages.

Docker Desktop and VS Code are optional. pnpm is required only when building from source. For MSI inputs, Windows uses msiexec.exe; Linux and macOS should use msitoolsand cabextract where available.

Installation

Install the packaged CLI from the supplied npm archive.

Download installers and browse all versions & release notes →

When you receive a licensed package, install its .tgz archive globally. The short command isli; lambogenius-integration-migrate is the long compatibility alias.

npm install --global ./lambogenius-integration-migration-cli-<version>.tgz
li --version
li --help

Contributors can build and package the CLI from the source workspace:

npm install --global pnpm@9.1.3
pnpm install --frozen-lockfile
pnpm run verify
pnpm run package:cli

Quick start

Configure and run a single migration.

1. 1
   Create a starter configuration.

   li config init --file migration.config.yaml

2. 2
   Edit source, application-starter, generated-output, report, provider, and policy settings.

   Keep source, starter, shared infrastructure, and pipeline-template repositories read-only.

   For the individual commands below, use single mode with a separately prepared writable application target and repository scaffolding disabled. Use batch mode when the CLI should copy a read-only starter into a generated target, even for one solution.

3. 3
   Validate configuration and provider authentication.

   li config check --config migration.config.yaml
   li auth status --provider codex

4. 4
   Run the persisted migration stages.

   li precheck --config migration.config.yaml
   li discover --config migration.config.yaml
   li plan --config migration.config.yaml
   li convert --config migration.config.yaml
   li test --config migration.config.yaml
   li package-deployment --config migration.config.yaml

5. 5
   Estimate Azure monthly running costs before deployment.

   li estimate-cost --config migration.config.yaml

   Open azure-cost-summary.md in the configured report directory. Review the environment, currency, monthly total, assumptions, and exclusions. Cost-estimation walkthrough →

6. 6
   Review status, reports, and recorded usage.

   li status --config migration.config.yaml

   Check each command's exit code and report before continuing. Batch runs also provide end-of-stage token summaries; direct single-stage commands do not currently provide that accounting. Status output can be incomplete even with exit code zero.

Add --log-file <path> to long-running stages. Use --log-level debug or--log-level verbose when troubleshooting.

Ways to work

Choose guided interaction or automation.

Stage reference

Use the narrowest command for the work you need.

Batch migrations

Discover solution directories and exported MSI packages recursively.

Point solutionsRoot at an estate directory. A directory with a root-level .slnbecomes one batch solution; each .msi becomes another. Explicit solution entries can override discovered entries with the same ID.

migration:
  mode: batch
  reportDirectory: ./reports
  batch:
    solutionsRoot: ../biztalk
    continueOnError: true
    concurrency: 1

li precheck --config migration.config.batch.yaml
li convert --config migration.config.batch.yaml --batch   --log-file ./logs/batch.log

Batch concurrency is currently limited to one. Keep batch state, reports, generated repositories, and conversion checkpoints if a run may need to resume. Add --resume only after a batch state file exists, not on the first run. Add --solution orders to run one configured solution through the same pipeline with per-stage token notifications.

A full batch automatically estimates Azure cost after packaging. --conversion-only omits that stage. Resume can reuse an existing cost summary without refreshing prices or assumptions; rerun li estimate-cost explicitly when those inputs change. Batch conversion does not deploy to Azure.

Cost estimation

Estimate Azure monthly running costs before deployment.

This stage calculates a retail planning estimate from generated infrastructure parameters and your configured assumptions. It queries the Azure Retail Prices API, not an AI model. It does not deploy resources, forecast migration tokens, or calculate your AI provider bill.

1. Finish generating the target's infra/ directory and environment .bicepparam files.
2. Review migration.costEstimation: environment, currency, hosting SKU, instance counts, workload, storage, monitoring, and supported networking assumptions. Review the region in the parameter file.
3. Run the command below, or let a full batch execute this stage after packaging. Network access to Azure retail pricing is required.
4. Open the reports and approve the assumptions and exclusions before authorizing deployment.

Single-stage configuration

li estimate-cost --config migration.config.single.yaml

One solution in a batch configuration

li estimate-cost --config migration.config.batch.yaml --solution orders

Omit --solution to estimate all batch solutions. Add --json for result summaries and report paths; open the referenced JSON file for detailed line items. In single-mode interactive CLI, use /estimate-cost, then /open cost. In Windows PowerShell, use li.cmdif the built-in li alias takes precedence.

Read the cost evidence

Under the configured report directory (or reports/<solution-id>/ for a batch using reportDirectory: ./reports), review:

azure-cost-summary.md
azure-cost-estimate-<timestamp>.md
azure-cost-estimate-<timestamp>.json

Reports include the selected parameter file, environment, region, currency, resource/SKU line items, quantities, retail prices, monthly total, assumptions, exclusions, and price meters. The indicative ±20% range is a simple calculation, not a statistical confidence interval.

Per-stage token usage

Read the usage notification at the end of each executed batch stage.

Full batch runs, including a batch with one solution, print recorded model usage when precheck, discovery, planning, conversion, test, packaging, and cost estimation finish or fail. Info logging is sufficient; no additional usage switch is needed. Save the notifications with --log-file ./logs/batch.log.

Illustrative log excerpts, not measured migration results or current Azure prices:

✓ [orders] Planning finished. Model tokens: 24,000 (20,000 input + 4,000 output across 5 calls). Open report: .../planning-summary.md
✓ [orders] Deployment package finished. Model tokens: 0 (0 input + 0 output across 0 calls). Open report: .../manifest.md
[orders] Estimated Azure cost: CAD <amount>/month (canadacentral).
✓ [orders] Cost estimation finished. Model tokens: 0 (0 input + 0 output across 0 calls). Open report: .../azure-cost-estimate-<timestamp>.md
✗ [orders] Conversion failed: Policy validation failed. Model tokens: 0 (0 input + 0 output across 0 calls)

Input tokens are recorded prompt/context usage; output tokens are recorded generated responses. Total is input plus output. Calls counts recorded model invocations, not Azure pricing HTTP requests. The report link opens stage evidence. Zero tokens for deterministic packaging and cost estimation is expected; it does not mean Azure hosting is free.

Skipped stages print already complete; skipped rather than the numerical completion line; their reports show no new stage usage. Stages not reached after a failure have no completion notice. A hard crash may prevent final notifications and usage reports from being written.

Keep the per-solution and batch reports

reports/<solution-id>/token-usage.md
reports/<solution-id>/token-usage.json
reports/migration-batch-<timestamp>.md
reports/migration-batch-<timestamp>.json

These paths assume reportDirectory: ./reports. Reports record per-stage input, output, total tokens, calls, exact/estimated count quality, and model execution duration. The final batch summary gives aggregate tokens and calls. Per-solution usage files are replaced on the next attempt; preserve them with the timestamped batch reports when you need history. Resume totals cover this attempt, not all prior runs.

AI providers

Use an authenticated supported provider CLI.

li auth login --provider codex
li auth status --provider codex

Provider credentials are managed by the provider CLI and are not stored in the migration configuration. Ollama runs locally and does not require remote login, but it requires a configured model and a running service.

Outputs and reports

Review the evidence behind every stage.

• Discovery: flow groups, per-flow analysis, architecture, components, dependencies, patterns, and gaps.
• Planning: target architecture, action mappings, resource selections, workflow designs, and artifact dispositions.
• Conversion: Logic Apps, Functions, infrastructure, tests, manifests, checkpoints, and generated repository changes.
• Validation: project build, policy, Bicep, and static deployment test results.
• Delivery: checksummed deployment packages, provenance, and explicit deployment records.
• Cost estimation: Azure monthly cost reports, assumptions, exclusions, and retail price meters.
• Batch usage: per-stage and per-solution token counts, aggregate totals, model-call counts, and model execution duration.

Use li status --config migration.config.yaml --json to inspect persisted artifacts. Parse the reported stage completeness when gating automation; the status command can exit zero with incomplete stages.

Safeguards

Keep source facts, generated changes, and deployment authority separate.

Troubleshooting

Start with configuration, status, and the persisted log.

Configuration file not found

Run from the intended directory or pass an absolute path with --config.

Provider authentication fails

Run li auth status --provider <provider>, then authenticate with the provider's own CLI.

Prerequisite stages are incomplete

Run li status, then finish discovery and planning before conversion.

Worktree already exists

Use --resume. Retain the worktree and checkpoint files until the run has been reviewed.

Generated path is outside the allowlist

Correct the project name or output layout. Broaden the allowlist only after intentional approval.

Azure Retail Prices API returns 429

Wait for the service retry interval, then rerun li estimate-cost.