Situation · Mission · Execution
OpOrder
Vendor-neutral assessment for cloud migration and application modernization — reads your code and your live infrastructure, tells you honestly what's actually there, and hands you a plan.
what a run looks like
$ oporder scan . OpOrder v0.1.0 · scanning ./ (git: main @ 4f2a91c) ⠋ Reading code................ 142 services detected ⠋ Connecting to your cloud.... AWS, GCP, Azure & Cloudflare — read-only ⠋ Fanning out assessment...... 142 workers, 3 fresh verifiers each ⠋ Pricing (live)............... AWS · GCP · Azure queried live, Cloudflare directional ⠋ Synthesizing report......... Done in 4m12s · $0.38 in LLM spend · full report: ./oporder-report/ 12 retain · 34 rehost · 41 replatform · 28 refactor · 9 rearchitect · 6 repurchase · 12 retire Biggest finding: billing-service has 4 undocumented dependencies on a deprecated internal API. See SITUATION.md#billing-service. Next: oporder report --open
illustrative — no run has produced these numbers yet; see the spec for why
why
Every existing agentic migration tool is built by a cloud provider with a stake in the answer. AWS Transform recommends AWS. Azure's tooling recommends Azure. That's not a flaw in those tools — it's their business model. OpOrder has no cloud to sell, so it can say things they structurally can't:
- "Retain this. Migrating it isn't worth it."
- "Repatriate this to on-prem — it's cheaper there."
- "Retire this. Nobody uses it."
A recommendation that costs the tool nothing to make is more trustworthy. That's the whole premise — and it applies just as much when nothing is moving providers at all. Modernizing a legacy monolith in place is exactly as much OpOrder's job as a cross-cloud migration is.
the seven calls it can make
Two of the seven are highlighted on purpose — retain and retire generate zero migration work, and they're weighted identically to the other five. A tool that can't reach either honestly isn't neutral, it's just slower than the vendor it's replacing.
what it produces
| Situation | The honest as-is: architecture diagram, dependency map, documentation — generated from your actual code and live infrastructure, not from what the wiki claims. |
|---|---|
| Mission | The recommendation: one of the seven above, per workload, with the reasoning and a counter-case shown. |
| Execution | Cost estimate, effort estimate, and sequencing — everything needed to hand to a build team, yours or anyone else's. |
what it deliberately doesn't do
OpOrder assesses and recommends. It does not execute. The moment the tool that makes the recommendation also profits from carrying it out, the recommendation stops being trustworthy — so OpOrder stops at the plan. If you want the work actually done, that's a separate, explicitly-scoped engagement with whoever you choose, Code To Cloud included.
● Early. Building in public. No released binary yet — the repository currently holds the full specification, not the tool.
Follow along, open an issue if you want to help shape where it goes, or drop into the Discord if you'd rather talk it through than write it up.