Free guide · Legacy to Power Platform

Rebuild any legacy app with REA + agents

REA (Reverse Engineer Anything) reads the old app nobody can explain. Agents rebuild it on Power Platform. Eight steps, one real example.

What REA is.

REA is an open source MCP server (MIT license). It lets your agent, such as Claude Code, Codex or Cursor, inspect compiled apps without their source code and explain how a feature works, with the evidence behind every conclusion. It reads native binaries through Ghidra, IDA or Hopper, .NET assemblies, JavaScript and Electron apps, websites and SQLite files. Analysis runs locally.

The morluto/rea repository on GitHub: Reverse engineer anything with agents, from app behavior down to native binaries. MIT license.
github.com/morluto/rea

The worked example: FieldDesk.

Every step below runs on one app: FieldDesk, a desktop dispatcher for a field service team. Work orders, technicians, certifications, SMS job alerts and emailed service requests, all locked inside a compiled .NET app and a SQL Server database.

Illustration of a legacy Windows dispatcher app, Contoso FieldDesk 2.4: a dispatch board grid of work orders with type, priority, status, scheduled date, technician and site, and buttons to assign a technician, mark complete and send a job sheet by SMS.
Illustration. We wrote FieldDesk for this guide, so we own it and may reverse engineer it. The REA output below is real.

The rebuild target is the Field Service app you build chapter by chapter in the Inner Circle book: the Dataverse model, the model-driven app, the assignment and completion flows, and the customer portal.

Map it. Free.

  1. 01

    Get the rights first Must

    Only analyze software you own or are authorized to examine. REA's own README says the same.

    1. Read the EULA or contract for reverse engineering terms.
    2. Get written OK from the app owner, which is usually your client.
    3. Use legally licensed tools only. Ghidra is free; IDA and Hopper are paid.
    4. Work on a copy, on your own machine. REA analysis runs locally.
    5. Never put client binaries or data in a public repo or chat.
  2. 02

    Connect REA to your agent Setup

    One command registers REA with your agent and installs its workflow instructions, with backups of your existing configuration.

    $ npx rea-agents setup
    1. Install Node.js 22.19 or later, and npm.
    2. Pick your agents: Claude Code, Codex, Cursor, Gemini CLI and more.
    3. Review the proposed changes, approve, then restart your agent.
    4. Native apps: point it at the Ghidra, IDA or Hopper you already have. .NET and JavaScript need no extra tools.
    5. REA changes fast. Update with npx rea-agents@latest setup.
  3. 03

    Point it at the app, one feature at a time Map

    Match the legacy app to what REA can read, then ask about one feature in plain English.

    1. VB6 or C++ .exe: native analysis through Ghidra, IDA or Hopper.
    2. .NET WinForms or WPF: assembly inspection, static, no extra tools. That's FieldDesk.
    3. Electron or JavaScript app: modules, routes and IPC.
    4. Web app: page structure, scripts and network, or a saved HAR capture.
    5. SQLite file: tables, columns, indexes and triggers.
    Explain how technician assignment works in Contoso.FieldDesk.dll. Show me the evidence.
    Terminal showing real REA 6.7.0 output for Contoso.FieldDesk.dll: the provider rea-dotnet-static loads no target code; methods Assign, Complete, DaysUntilScheduled and ImportServiceRequest; and the string literals, including Installations need an INSTALL-L2 certified technician, Critical work orders need a senior technician, Technician already has 6 open work orders, the UPDATE WorkOrders SQL and the New job assigned message.
    Real REA output on FieldDesk, trimmed. No source code, no symbols: the business rules come straight out of the compiled app.
  4. 04

    Triage the evidence Map

    REA returns each finding with its evidence and its limits, and says what it can't see. Label every finding.

    1. Seen (code, strings or calls cited): write it into the spec.
    2. Inferred: confirm it with the people who use the app.
    3. Unknown: take it to a workshop with the business.
    4. Keep a feature map: one row per feature, with its evidence.
    5. That map is your backlog for steps 5 to 8.
    The FieldDesk feature map: seven rows. Assign a technician, notify the technician, complete a job, ask for feedback and service requests are Seen; tables and columns are Inferred; who may do what is Unknown. Each row lists the REA evidence and the Power Platform rebuild target with its book chapter.
    The FieldDesk feature map. Every row points at the chapter that rebuilds it.

Rebuild it. Inner Circle.

Steps 5 to 8 turn the FieldDesk map into the Field Service app from the book, row by row: the exact prompts, the review checkpoints and the parity tests.

  1. 05

    Model the data Inner Circle

    WorkOrders, Technicians, ServiceLocations and Certifications become Dataverse tables with the fs_ prefix, status reasons instead of status columns, and the technician to certification relationship.

    Chapter 3: Dataverse, the Field Service data model
    The Field Service model-driven app scheduling board from Chapter 3, with technicians, booked work orders and an unscheduled queue.
  2. 06

    Rebuild screens and logic Inner Circle

    The dispatch board becomes a model-driven app. The SMS job alert becomes the assignment notification flow. Emailed requests become the customer portal's Request service page.

    Chapters 3, 4 and 5: model-driven app, flows, Power Pages
    Claude Code building the WorkOrderAssignmentNotification flow from Chapter 4 in a Dev environment.
  3. 07

    Prove parity Inner Circle

    Every Seen finding becomes a test case: an INSTALL-L2 check, a senior-only Critical job, the 6-job cap, completion without sign-off. Same inputs, same outputs, old and new side by side.

    Chapter 13: quality gates for AI-generated assets
    The rebuilt Field Service customer portal dashboard from Chapter 5.
  4. 08

    Lock it down Inner Circle

    FieldDesk trusted anyone with a Windows login. The rebuild gets security roles, table permissions scoped to each customer, and server-side rules, then a security review before go-live.

    Chapters 5 and 13: table permissions, security review, governance
    Solution checker enforcement settings from Chapter 13.

Reading it is step one. Building it is the point.

Here's how people go from saving a post to shipping the rebuild.

  1. You're here

    The free playbook

    Steps 1 to 4, the worked example and the PDF. Yours to keep.

    Download the PDF
  2. Free

    The Builder's Journey

    Two free hands-on labs: Dataverse and a model-driven app with AI plugins. Every step is checked, and you earn a verifiable badge.

    Start the free labs (opens in new tab)
  3. Members

    The Inner Circle

    Steps 5 to 8 on FieldDesk, the Field Service chapters behind them, every lab and weekly live builds with Victor. Try it free for 7 days.

    Start the 7-day free trial

Want the whole path? See the Builder's Journey.