Our Lisbon legacy modernization follows a low-risk methodology: assess, plan, execute incrementally, and validate continuously. Assessment (weeks 1-2): understanding the legacy system. We analyse the existing system comprehensively: codebase analysis (for applications with available source code — code quality assessment, dependency analysis, architecture mapping, and technical debt inventory. For applications without source code or documentation — reverse engineering functionality through user observation and database analysis), database analysis (schema examination, data volume assessment, data quality audit, and relationship mapping. For Access databases: identifying design limitations — table size limits, query complexity limits, and multi-user access issues), business logic extraction (the most critical phase — understanding what the application actually does, not what documentation says it does. Business logic often lives in: database stored procedures, application code, spreadsheet formulas, email rules, and the heads of experienced users. We document all business logic regardless of where it currently resides), integration mapping (what other systems connect to the legacy application — data flows in and out, frequency of data exchange, and the format and protocol of each integration), and user workflow documentation (how users actually use the system — the screens they visit, the data they enter, the reports they generate, and the workarounds they use for system limitations. User workflows inform the modern application's UX design). Modernization strategy (week 2-3): choosing the right approach. Not every legacy system should be rewritten from scratch. We evaluate three strategies: re-platform (move the application to modern infrastructure without changing functionality — e.g., migrating a .NET Framework application to .NET 8, or migrating an Access database to SQL Server with a web frontend. Lowest risk, fastest timeline, but limited improvement in functionality), incremental replacement (the strangler fig pattern — building modern replacements for individual features while the legacy system continues operating. New features served by the modern application; old features gradually migrated. Risk spread over time, with the legacy system as a safety net throughout), and complete rebuild (building the application from scratch on modern technology — using the business logic extracted from the legacy system as the specification. Highest risk and longest timeline, but the best outcome for systems where the architecture is fundamentally incompatible with modern requirements). Our recommendation: based on the specific system. We default to incremental replacement for large systems (lower risk) and complete rebuild for smaller systems (the strangler fig overhead isn't justified for applications with fewer than 20 features). Development (weeks 3-14): building the modern application. Technology stack: Next.js (web application — replacing Windows Forms, Access forms, or PHP pages with modern, responsive web interfaces), PostgreSQL (replacing SQL Server, Access, or MySQL — with data migration scripts that preserve all historical data), and Node.js or Python (API layer — implementing the business logic extracted during assessment). Data migration: the most risk-sensitive phase. We migrate data iteratively: schema migration (designing the modern database schema — normalising data that was denormalised in the legacy system, adding constraints that the legacy system didn't enforce, and preserving data relationships), data transformation (converting legacy data formats to modern formats — date formats, character encodings, numerical precision. For Portuguese data: handling Portuguese character encoding — many legacy systems using ISO 8859-1 or Windows-1252, requiring conversion to UTF-8), data validation (comparing migrated data against source data — automated record counts, checksum verification, and sample-based manual verification. Every row: accounted for), and parallel running (the modern system and legacy system running simultaneously for 2-4 weeks — same data entering both systems, results compared daily. Discrepancies investigated and resolved before cutover). Cutover and decommission (weeks 12-16): switching to the modern system. Cutover: planned for a low-activity period (Friday evening or weekend), with a defined rollback plan (if the modern system fails during the first week, revert to the legacy system — the rollback capability maintained for 2-4 weeks post-cutover). Legacy system: not immediately decommissioned. Read-only access maintained for 6-12 months (users may need to reference historical data in the legacy format, and compliance may require access to the legacy system's audit trails). Final decommission: after confirming that all data has been migrated and all compliance requirements are met.