Our Cape Town legacy modernization follows a methodology designed for zero-data-loss migration: (1) Legacy assessment (weeks 1-2): understanding what exists. Code analysis: examining the legacy codebase — language, framework, database, business logic, and code quality. South African legacy: common findings include VB6/Delphi with embedded SQL queries, business logic mixed with UI code, and hard-coded South African business rules (VAT calculations, SARS reporting formats). Database analysis: mapping the legacy database — tables, relationships, data types, data volume, and data quality. South African databases: SQL Server (most common), Access MDB files, Paradox (Delphi), and FoxPro DBF files. Business process mapping: documenting what the application does — often the legacy code is the only documentation. South African legacy: the original developer often unavailable — reverse-engineering business logic from code and user observation. User interviews: talking to the people who use the system daily — understanding their workflows, pain points, and requirements. Cape Town users: often deeply knowledgeable about the application's quirks and workarounds — invaluable input for the modernized system. Data sensitivity: classifying data for POPIA — personal information, special personal information, and non-personal data. POPIA readiness: planning compliance improvements for the modernized system. (2) Modernization strategy (weeks 2-3): choosing the right approach. Strategy options: rebuild (building new application from scratch using modern technology — recommended when the legacy code is unmaintainable and the business process has evolved significantly), replatform (migrating to a modern technology stack while preserving the core logic — suitable when the business logic is sound but the technology is outdated), replace (replacing the custom application with a commercial product — suitable when the legacy application's function is now available as a standard product), and wrap (putting a modern API/UI layer around the legacy application — suitable as a short-term solution while planning a longer-term modernization). Cape Town recommendation: rebuild is most common — South African legacy applications typically having code quality and architecture that doesn't justify preservation. The rebuild: designed with the benefit of 15-20 years of accumulated business knowledge. Technology selection: choosing the modern stack — Next.js (web application), React Native (mobile), PostgreSQL (database), and AWS/Azure (cloud hosting). Cape Town technology: selecting technologies with strong developer availability in Cape Town — ensuring the new system can be maintained by locally available talent. (3) Data migration (weeks 3-5): the most critical phase. Data extraction: extracting all data from the legacy database — every table, every record, every relationship. South African data: handling legacy character encoding (some older systems using Windows-1252 rather than UTF-8), South African date formats, and legacy data types. Data cleaning: identifying and resolving data quality issues — duplicates, inconsistencies, missing values, and invalid data. Legacy data: often containing 15-20 years of accumulated data quality issues — cleaning before migration rather than migrating problems into the new system. Data transformation: mapping legacy data structures to the modern database schema — normalising denormalised data, splitting combined fields, and establishing proper foreign key relationships. Migration scripts: automated, repeatable migration scripts — tested multiple times before the production cutover. Zero data loss: the absolute requirement — every record in the legacy system present and verified in the new system. Verification: automated comparison — record counts, checksums, and sample verification ensuring complete migration. (4) Application development (weeks 4-8): building the modern system. Feature parity: first priority — the new system doing everything the legacy system does (that users still need). South African feature: ensuring South African business requirements are maintained — VAT calculations, SARS reporting, and POPIA compliance. Enhancement: second priority — improvements enabled by modern technology (mobile access, real-time dashboards, automated reporting, and integration). Cape Town enhancement: mobile access (enabling field work during load shedding when the office is without power), cloud hosting (eliminating load shedding impact on the application), and automated SARS reporting. User training: training users on the new system — designed for change management, not just feature training. South African change: some users having used the legacy system for 10-15 years — change management being critical for adoption. (5) Cutover (weeks 8-10): switching from old to new. Parallel running: old and new systems running simultaneously for 2-4 weeks — users verifying the new system produces correct results. Data sync: during parallel running — changes in the legacy system reflected in the new system (one-way sync). Production cutover: planned transition — typically a weekend, with the legacy system shut down and the new system becoming the primary. Rollback plan: tested rollback procedure — if critical issues arise in the first week, the legacy system can be reactivated. Post-cutover support: intensive support for 2-4 weeks after cutover — rapid response to any issues or questions.