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.
v0.1.0 is real and tagged — macOS & Linux, Intel & ARM64. No Go toolchain, no build step. Prefer npm? npm install -g oporder works the same way. Or grab a binary directly from GitHub Releases.
watch a real scan run
real, recorded output from oporder scan against
this actual public repo —
code-only, no cloud account involved, reproducible with oporder scan after
installing above. This replays a captured run; it isn't live and doesn't execute anything
on your machine.
View the real SITUATION.md this run produced
the fuller vision — not built yet
$ oporder scan . OpOrder · 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, but v0.1.0 is real and tagged.
Code workload-detection, proprietary-SDK scanning, live read-only connectors for AWS,
Azure, GCP, and Cloudflare, a partial-evidence 5/7-Rs call, and a plain-English write-up
per workload — all wired together into a working oporder scan command that
needs no cloud account to be useful, and produces more when you give it one. Not the
full vision yet: no Well-Architected scoring, security baseline, cost/effort estimate,
or TUI. See the spec for the honest milestone-by-milestone status.
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.
Real installers, both downloading the actual v0.1.0 binary for your platform (macOS & Linux, Intel & ARM64):
brew trust is current
Homebrew's own requirement for any third-party tap, not specific to this one. Windows
binaries exist on the release page
but npm/Homebrew aren't wired up for Windows yet.