Choose migration boundaries
- Inventory forms, modules, classes, COM servers, controls, API calls and data-access paths.
- Characterize critical workflows and edge cases before changing implementation.
- Separate reusable business rules from UI, persistence and device integration.
- Decide which components can remain behind COM interoperability during a staged transition.
- Replace unsupported OCX controls by behavior, not by visual resemblance alone.
A UI rewrite, data-layer change and runtime migration performed simultaneously creates too many unknowns. An incremental boundary—service, component, workflow or data interface—allows old and new results to be compared.
Test what conversion tools cannot prove
| Variants and defaults | Null, Empty, coercion, optional parameters and error behavior. |
|---|---|
| Data access | Cursor, locking, transaction, parameter and SQL semantics. |
| Windows/COM | Apartment model, callbacks, registration, API types and 32-bit dependencies. |
| UI workflow | Event order, validation, focus, printing and operator timing. |
Use production-like datasets and golden outputs, then run old and new implementations in parallel where operationally safe. A rewrite is riskier when undocumented behavior cannot be independently specified.
See VB6 modernization, behavior recovery, database modernization and the VB6 pillar.