---
type: project
name: valleywide-orders-modernization
display_name: Valley Wide "Orders" App Modernization
client: valleywide
status: active
last_compiled: 2026-06-14
compiled_by: Mikes-MacBook-Air/claude-main
sources:
  - clients/valleywide/app-modernization/CONTEXT.md
  - clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/
  - clients/valleywide/app-modernization/docs/MODERNIZATION_ROADMAP.md
  - clients/valleywide/session-logs/2026-06/2026-06-13-mike-vwp-server3-migration-and-orders-source-recovery.md
  - clients/valleywide/session-logs/2026-06/2026-06-14-mike-orders-modernization-roadmap.md
  - wiki/clients/valleywide.md
backlinks:
  - clients/valleywide
---

# Valley Wide "Orders" App Modernization

Assessment + modernization of Valley Wide Plastering's custom construction ERP, an in-house VB6
application called **ORDERS** (`Orders_10A.exe` / `ORDERS.exe`). The original developer ("Darv")
is deceased. The app still runs production but is on a dead stack (VB6 + Jet/Access) and is
approaching the 2 GB Jet file-size wall. ACG engaged to assess feasibility and a path forward.

**Tracking ticket:** Syncro **#32280 — Source Code Data Recovery** (id 110305931).

---

## STATUS HEADLINE (2026-06-13): SOURCE FULLY RECOVERED

The complete VB6 source was believed lost (only `frmPayroll.frm` had ever been found). On
2026-06-13 it was **recovered in full** from Darv's machine backup (`F:\Darv\Darv.rar`, 51 GB, on
WINFileSvr `192.168.0.35`, extracted to `F:\Darv\Darv-rar`). The full ORDERS project tree is
present with multiple versions; newest **`…\Kingston\Project\VWP_Current\ORDERS_C.vbp` (2020-06-09)**.

12.2 MB of pure source is staged in the repo at
`clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/` (147 `.frm`, 4 `.bas`,
5 `.vbp`, 2 `.Dsr`). **VB Decompiler Pro is no longer needed** — modernization can proceed from
real, buildable 2020 source.

---

## The Application

ORDERS is a full **construction ERP for a plastering/stucco subcontractor**. The `ORDERS_C.vbp`
project links ~40 active forms (the folder holds 128 `.frm` total, many being Darv's `old`/`bak`/`xx`
working copies). Form names map cleanly onto the documented Jet schema (`tbl…` in
[[clients/valleywide]]):

| Domain | Forms (representative) | DB tables |
|---|---|---|
| Projects & Lots | frmProject, frmLotInfo, frmPlans, frmLotOrders, frmChange, frmLotChLog | tblPROJECT, tblLOTINFO, tblPLANS, tblCHANGE |
| Orders & Takeoffs | frmOrders, frmTake, frmViewTake, frmInvTake, frmOrderDates | tblORDERS, tblTAKE, tblMEASURE |
| Crew / Labor / **Payroll** | frmCrew(s), frmEmployee, frmLabor, frmPayroll, frmPayHead, frmPaySheet, frmHourList | tblCREW, tblHRDAILY, tblPAYHEADER, tblPAYROLL |
| **Certified Payroll** | frmCertified | **tblCERTIFIED** (prevailing-wage, legal HARD requirement) |
| Scaffold | frmScaffold, frmScafList, frmScafPay, frmSCrew | tblScaffold, tblSC_Crew |
| Inventory / Purchasing | frmInventory, frmInvPrice, frmYardOrder, frmPO, frmPOList, frmPOMatrl, frmSupplier, frmContractor | tblINVTRY, tblINVPRICE, tblSUPPLIER, tblPOrder, tblYardOrder |
| AR / AP / Billing / Job Cost | frmAR(Master), frmAP(Master), frmBilling, frmMANBILL, frmJCList, frmJCPrint | tblARMASTER, tblAPMASTER, tblJOBCOST |
| **Positive Pay (3 banks)** | frmPosPayC, frmPosPayS, frmPosPayV | **tblPosPayCRD, tblPosPaySWI, tblPosPayVWP** (bank fraud-prevention, HARD dependency) |
| Repairs | frmRepair, frmRepairLot, frmRepList | tblREPAIR, tblRepList |
| Materials/Finishes | frmTexture, frmFoam, frmSand, frmBlackPaper | — |
| System | frmLogin, frmUser, frmMain, frmSplash, frmAbout, frmError, frmReport | tblSECURITY, tblSYSInfo |

---

## Technology Stack (confirmed from `ORDERS_C.vbp` references)

- **Language/runtime:** Visual Basic 6.0, compiled **P-Code** (best case for any fallback
  decompile — ~70-80% recoverable — but moot now that we have source).
- **Data access:** ADO 2.6 (`msado26`), MS ADO Data Control (`MSADODC.OCX`), RDO 2.0 (`msrdo20`),
  ADOX DDL (`msadox`) → **MS Jet / Access `.mdb`** (Jet 3.x, Access 97 format).
- **Reporting:** **Crystal Reports 7** ActiveX runtime (`craxdrt.dll`, `Crystl32.OCX`) + MS Data
  Report 6.0 (`MSDBRPTR`, `DataReport1.Dsr`, `CrystalReport2.Dsr`). (~791 `.rpt` files documented.)
- **Grids:** **True DBGrid Pro 7.0** (`todg7.ocx`, `tdbg7da`) + MS FlexGrid.
- **Spreadsheet grid:** **FarPoint Spread** (`Flp32a30.ocx`).
- **UI controls:** TABCTL32 (tab control), MSCOMCTL / mscomct2 (common controls), comdlg32,
  `EasyP.ocx` (EasyPrint).
- **Misc:** MSXML 4.0, Scripting Runtime, MS Data Binding (`MSBIND`), data formatting (`msstdfmt`).

Data layer is centralized in **`ADO.bas` / `ADO2.bas`** (the `modADO` module) — the place to start
when reading the code.

---

## Database

- Custom Jet/Access ERP, **~130 tables**. Production DB `VWP.mdb` was **938 MB (2026)** and growing
  (671 MB 2020 → 761 MB 2022 → 938 MB 2026) — **approaching the 2 GB Jet hard limit** (the core
  modernization driver). Multiple `.mdb` copies exist in the Darv backup (e.g.
  `…\000_ASource\Vwp.mdb` 801 MB, `…\VWP\db1.mdb` 120 MB) — left on the server, not in the repo.
- Modern ACE/DAO drivers refuse to open the Jet 3.x file; earlier schema extraction was via binary
  scan. With source in hand, the schema can now be read directly from the forms' SQL + `modADO`.

---

## Modernization Assessment

### Constraints that shape every option
- **Certified payroll** (prevailing-wage gov't jobs) — legal compliance, cannot be dropped.
- **Positive Pay** to 3 banks (CRD/SWI/VWP) — fraud-prevention integration, hard dependency.
- **~791 Crystal Reports** — a large, separate reporting surface to carry or replace.
- **Heavy commercial OCX dependency** (True DBGrid, FarPoint Spread, Crystal) — these, not the VB6
  language, are the migration's hard part. Lesson from the field: business rules hide in grid event
  handlers — favor migration that preserves logic over a clean-room rewrite.

### Strategy options (industry-standard for VB6 + Jet)
1. **Automated migration to .NET (C#/VB.NET)** — baseline-convert with **VBUC** (Mobilize.Net /
   gapvelocity "VB6 AI Migrator"; targets up to .NET 8, multi-project), then manual refactor.
   Preserves ~25 yrs of business logic. **Recommended baseline.**
2. **Incremental / strangler** — expose VB6 via COM/services, rewrite module-by-module; old+new
   coexist. Lowest risk, longest timeline.
3. **Full rewrite** (web/.NET) — only justified if the code is unsalvageable; discards the logic
   investment and risks the "47 undocumented rules" trap.
4. **Hybrid** — keep stable parts on VB6, rewrite the high-value/at-risk parts (data layer + the
   Jet→SQL move first).

### The OCX/report dependencies have direct .NET successors (key finding)
The three commercial controls map cleanly onto modern equivalents from the **same vendor lineage**
(MESCIUS / GrapeCity / ComponentOne — formerly FarPoint), which de-risks the migration:
- **True DBGrid Pro 7 → ComponentOne/MESCIUS FlexGrid** (recommended .NET successor; True DBGrid Pro
  8 also exists with a migration utility).
- **FarPoint Spread (ActiveX) → Spread for WinForms (.NET)** — convert `.ss2` designs to XML via the
  GrapeCity Spread designer; same vendor.
- **Crystal Reports 7 → Crystal Reports for Visual Studio** — auto-converts older projects on open
  (or re-platform reports to a modern engine long-term).
- **Jet/Access `.mdb` → SQL Server** — removes the 2 GB wall, adds proper concurrency/security;
  data-access already abstracted in `modADO`, easing the swap.

### Suggested first concrete steps
1. Stand up a **VB6 IDE build environment** (VB6 SP6 + the OCX set: TABCTL32, todg7, Flp32a30,
   Crystl32/craxdrt, MSCOMCTL, EasyP) and confirm `ORDERS_C.vbp` **compiles from the recovered tree**.
2. Migrate **Jet → SQL Server** behind `modADO` first (biggest pain, lowest UI risk).
3. Pilot a **VBUC** conversion of one self-contained module to gauge effort + control-replacement cost.
4. Inventory the 791 `.rpt` against what's actually used before committing to a reporting path.

---

## Modernization Roadmap (2026-06-14)

A comprehensive 7-phase roadmap has been established for migrating ORDERS from VB6/Jet to a modern web application. The strategy uses a **dual-client architecture** (strangler pattern) where both VB6 and web clients share the same SQL Server backend during development, enabling gradual module-by-module migration with real-user beta testing.

**Full roadmap:** `clients/valleywide/app-modernization/docs/MODERNIZATION_ROADMAP.md`

### Core Strategy

1. **Jet → SQL Server migration first (Month 1)** — Removes 2GB limit and Win7 VM dependency. VB6 `modADO.bas` updated for SQL Server connection strings.
2. **Dual-client architecture (Months 2-9)** — VB6 and web client coexist, both accessing SQL Server. Enables live-beta platform with 3-5 real users testing web modules while production continues on VB6.
3. **Module-by-module rollout** — Read-only modules first (project lists, reports), then light data entry, then complex modules, with certified payroll and positive pay last (compliance-critical).
4. **Single cutover to SQL storage** — No migrate-twice. Once SQL Server is live, both clients use it. Web client gradually replaces VB6 modules until full cutover.

### Timeline (8-9 Months)

| Phase | Duration | Focus | Key Deliverables |
|---|---|---|---|
| 1: Foundation & Database | Month 1 | Jet→SQL migration, modADO update | SQL Server live, VB6 on SQL verified |
| 2: Web Foundation & API | Month 2 | REST API, auth framework | API layer operational, auth working |
| 3: Read-Only Modules | Months 2-3 | Project lists, reports, view-only forms | 3-5 beta users testing read access |
| 4: Light Data Entry | Months 3-4 | Simple CRUD forms (inventory, contacts) | Beta users entering new data via web |
| 5: Complex Modules | Months 5-6 | Takeoffs, change orders, job costing | Core business logic migrated |
| 6: Compliance Modules | Months 7-8 | Certified payroll, positive pay (3 banks) | Legal requirements met in web client |
| 7: Full Rollout | Months 8-9 | Remaining modules, training, cutover | All users on web client, VB6 retired |

### Technical Safeguards

- **Row versioning** — SQL Server optimistic concurrency prevents VB6/web conflicts
- **Feature flags** — Per-module rollback capability if web version has issues
- **Audit logging** — Track which client type (VB6/web) performed each operation
- **Blazor Server/.NET 8 recommended** — Strong data binding for complex forms, .NET ecosystem alignment

### Risk Mitigation

- **Crystal Reports** — 791 reports preserved initially via Crystal for .NET runtime; gradual re-platforming to modern reporting engine (SSRS/DevExpress) in Phase 7
- **OCX grid logic** — Business rules in True DBGrid/FarPoint event handlers migrated to API layer validation + web UI bindings
- **Beta user feedback loop** — Each module tested by 3-5 users before general rollout
- **Parallel operation** — VB6 remains production-ready throughout; web rollout is additive, not replacement, until Phase 7

---

## Source Code Status & Locations

- **Recovered tree (repo):** `clients/valleywide/app-modernization/source-code/Orders-VWP_Current-2020/`
  (newest `ORDERS_C.vbp` 2020-06-09; also `ORDERS_Cx`, historical `ORDERSold.vbp` 2002 /
  `ORDERSSave`). Plus `000_ASource/TEST_VWP.vbp` (a LotInfo test harness) and the `darv-G-finds/`
  binaries (`ORDERS0727-2015.exe`, `ORDERS-2005.exe`, `Package1508` installer + the OCX set).
- **Source of record (server):** WINFileSvr `192.168.0.35` — `F:\Darv\Darv.rar` (51 GB archive) and
  `F:\Darv\Darv-rar` (135 GB extract). Also present: `VWP_Inv` (inventory) and `VWP_Update` projects
  (not yet staged). Keep until the source is verified to compile, then the 135 GB extract can be
  cleaned up.
- Compiled production build is `Orders_10A.exe`; the running app is launched via shortcuts to it.

---

## History

| Date | Event |
|---|---|
| 2026-04-27 | App-mod project initiated. VB6 P-Code + Jet 3.x stack confirmed; ~130 tables extracted via binary scan; Crystal 8.5 / 791 `.rpt` documented. Decompilation planned. |
| 2026-05-14 | Ticket #32280 "Source Code Data Recovery" opened. |
| 2026-05-16 | VB6 source search across server drives (D/drive2/drive3 scans) — substantial VB6 found, confirming which is VWP's was in progress. |
| 2026-06-13 | **Full source recovered** from `Darv.rar` (WINFileSvr). Staged to repo; decompilation retired. Found during the SERVER3→VWP-FILES G: migration server sweep. |
| 2026-06-14 | **Modernization roadmap established.** 7-phase dual-client strategy (8-9 months): Jet→SQL migration first, then gradual web development with strangler pattern. Syncro ticket updated with source recovery announcement. |

---

## Reference

- **Ticket:** #32280 (id 110305931), customer 31694734.
- **Repo:** `clients/valleywide/app-modernization/` (CONTEXT.md, source-code/, source-analysis/).
- **Newest project:** `ORDERS_C.vbp` 2020-06-09 — Type=Exe, 80 forms + `modADO`, 10 OCX/13 references.
- **Related:** [[clients/valleywide]] (client + the 2026-06-13 G: migration to VWP-FILES).

### Modernization research sources
- Mobilize.Net VBUC (VB6→C#/.NET 8): https://www.mobilize.net/products/app-migrations/vbuc/c-generation
- VBUC third-party / ActiveX control handling: https://docs.gapvelocity.ai/vbuc/third-party-controls
- True DBGrid → FlexGrid (.NET) / migration utility: https://developer.mescius.com/kb/using-the-true-dbgrid-pro-80-migration-utility
- FarPoint Spread ActiveX → Spread for WinForms (.ss2→XML): https://www.gapvelocity.ai/blog/migrating-activex-farpoint-grid-designer
- VB6 modernization strategies (big-bang / strangler / rewrite / hybrid): https://dzone.com/articles/migrating-legacy-applications-modern-platforms
