Migration Guide

Access to New Server Migration Summary

1. Standardize Naming in Access DB

• Rename modules consistently:
  • Classes as cls_TableName
  • Regular modules modModuleName
  • Controllers as TableRowObjectController e.g. EntityController
  • Forms as Form_Name
  • Reports as Report_Name
• Do this before further migration or development work to reduce confusion.

2. Table-by-Table Migration Workflow

• Choose a table.
• Build matching model in the new database with proper naming conventions (snake_case).
• Locate all Access code related to that table: classes (cls_), controllers (ctl_), forms, reports.
• Create or update the controller module (ctl_TableName) in Access to act as a clean interface between forms and data classes.
• Redirect all Access data interactions through these controllers going forward.

3. Parallel Development Approach

• Work on Access cleanup and new server migration concurrently but focus on one table/module at a time.
• Avoid spreading effort thin across too many tables simultaneously.

4. Refactoring and Cleanup

• Keep logic that is not UI-related in controllers or classes, separate from forms.
• Gradually refactor bad or mixed code into clean controllers.
• Use new server as the source of truth once migrated and tested.

5. Testing and Validation

• After migrating each table and its logic, thoroughly test in Access with updated controller calls.
• Sync with new server endpoints or database as applicable.

---

This structured approach minimizes risks, keeps legacy code manageable, and eases migration.