Quick Summary
A data migration is the process of moving data from one system or storage environment to another — for example, from a legacy accounting system to a new ERP, from an on-premise file server to SharePoint, from a local email server to Microsoft 365, or from one database platform to another. Data migrations are among the highest-risk activities in IT projects: poorly executed migrations result in data loss, corrupt data, missing records, and operational disruption at the exact moment the business is transitioning. A structured process — with assessment, cleansing, mapping, test migration, validation, and rollback planning — is the difference between a successful cutover and a failed one.
Common Migration Scenarios for Ethiopian Businesses
| Migration Type | From | To | Key Challenges |
|---|---|---|---|
| ERP implementation migration | Spreadsheets, legacy accounting, multiple disconnected systems | New ERP (Odoo, Dynamics 365, ERPNext) | Data quality — cleaning years of inconsistent data; mapping legacy data into ERP model; opening balance accuracy; staff training |
| Email migration | Local mail server (Exchange, Postfix), cPanel email, Gmail | Microsoft 365 Exchange Online, Google Workspace | Preserving history; migrating shared mailboxes and distribution lists; DNS cutover; Outlook profile reconfiguration |
| File server to cloud migration | On-premise Windows file server, NAS | SharePoint Online, Google Shared Drives, OneDrive | Volume (TB of data over Ethiopian internet); permission mapping; folder structure design; user adoption |
| Database platform migration | MySQL, MSSQL, Access, legacy proprietary database | PostgreSQL, MySQL, SQL Server, cloud database | Schema differences; data type conversion; application compatibility; maintaining referential integrity |
| Hardware / server migration | Ageing hardware, end-of-life servers | New server hardware, virtualisation, cloud | System downtime; P2V conversion; application compatibility on new environment; backup of source |
The Data Migration Process
Step 1: Discovery and Data Assessment
Identify and document all data to be migrated: sources, volumes, types, age, and quality. Assess source data quality — duplicates, inconsistencies, missing values, obsolete records. Discovery often reveals data quality problems that should be resolved before migration.
Step 2: Data Cleansing
Clean source data before migration: remove or merge duplicates; correct inconsistencies; fill missing required fields; remove obsolete records; standardise naming. Cleansing is time-consuming and almost always underestimated. Migrating dirty data creates dirty data in the new system.
Step 3: Schema Mapping
Define how each source field maps to the target field. Not all fields will have direct equivalents; some target fields may be mandatory that were optional; some may need to be combined or transformed. Mapping is documented in a specification that guides migration scripts or tool configuration.
Step 4: Test Migration
Execute migration into a test environment (not the live target) and verify against the mapping specification. Test migrations identify errors, data conversion problems, and missing data before they affect production. Multiple iterations typically resolve issues.
Step 5: User Acceptance Testing (UAT)
Key business users validate the migrated data in the test environment — verifying records are complete, accurate, and accessible. UAT is the business's confirmation, not the IT team's. Issues found after cutover require urgent remediation while the business is running on the new system.
Step 6: Cutover Planning
Define the cutover approach, exact timeline, freeze point, rollback plan if cutover fails, and communication plan. The cutover should have a detailed minute-by-minute runbook covering every step.
Step 7: Live Migration and Validation
Execute the migration to the live system. Validate against the UAT-approved benchmark — record counts, spot-check critical records, run key business reports. Only release to users when validation is complete and business sign-off given.
Big-Bang vs Phased Migration
| Approach | Description | Advantages | Risks |
|---|---|---|---|
| Big-bang (cutover) | All data migrated in a single window; source retired immediately after | Clean break; single system from day one; no parallel running cost | Higher risk — all issues manifest at go-live; requires thorough testing; rollback is complex |
| Phased | Migration in stages — by data category, department, or date range | Lower risk per phase; issues resolved before next phase; allows learning between phases | Longer transition; parallel running creates complexity; staff may resist full adoption while old system exists |
Always back up before migrating: A full backup of the source system should be taken immediately before any production migration begins. If the migration fails or produces unexpected results, the backup is the rollback option. Do not begin a production migration without a verified, restorable backup of the source data.
Frequently Asked Questions
How long does a data migration take for an Ethiopian business?
Duration depends on complexity and the volume and quality of source data. An email migration for 20 users to Microsoft 365 typically takes one to two days including testing and cutover. A file server migration with 500 GB of data over an Ethiopian internet connection may take several days for the initial upload. An ERP implementation migration — with cleansing, mapping, test migrations, and UAT — typically takes four to eight weeks as part of the broader ERP project. Data cleansing is almost always the longest single component.
Do we need to migrate all historical data to the new system?
Not necessarily — and migrating all historical data is often not the correct decision. For ERP migrations, it is common to migrate only a defined period of transaction history (typically 12 months) as active data, and to archive older records in read-only form or in the legacy system for reference. This limits migration complexity, improves performance in the new system, and avoids migrating decades of inconsistent legacy data. The retention decision should be made as part of migration planning — aligned with ERCA requirements and business reporting needs.
Data Migration Services for Ethiopian Businesses
Bright IT Solutions plans and executes data migrations for Ethiopian organisations — from ERP implementation migrations and email migrations to file server-to-cloud and database platform migrations.
Prefer to talk first? Contact us