Article summary
Migrate an Ethiopia +251 legacy CRM without guessing missing digits. This runbook covers source preservation, numbering-rule versions, exception queues and full-format acceptance.
An Ethiopia WhatsApp Full-Format check should begin with a more basic question: can each legacy phone be reconstructed without guessing? An old CRM may contain domestic dialling notation, explicit +251 numbers, spreadsheet scientific notation, duplicate contacts and short values with no reliable country provenance. Sending that mixture directly to a checker makes input damage look like a platform result.
This runbook treats migration as an auditable data operation. The goal is not to force every row into a valid-looking shape. It is to explain every transformation and give ambiguous records a safe destination.
Step 1: freeze the source and identify the damage
Copy the source table, import the phone column as text, and preserve phone_raw. Do not remove zeroes, prepend a country code or overwrite the original column in bulk. Once the source is altered, it becomes much harder to tell which system produced the value or which dialling convention it used.
| Legacy symptom | Likely cause | Safe to automate? |
|---|---|---|
| 8.******E+11 | A spreadsheet stored the phone as a number | No; recover text from the source system |
| Begins with 0 and has no country code | Possible Ethiopian national notation | Only with trustworthy country provenance |
| +251 followed by an extra trunk zero | A country code was prepended without transforming national notation | Propose a candidate and log the rule |
| Too few digits | Truncation, copy failure or a lost leading character | No; never pad with a common prefix |
| Several phones under one contact | Changed SIM, secondary phone or multiple business contacts | Do not merge on name alone |
Step 2: version +251 rules instead of hard-coding one expression
The Ethiopian Communications Authority establishes and administers the country’s numbering plan. Its Telecommunications Numbering Directive No. 795/2021 says the allocation status and use conditions for codes and blocks should be kept current and published at least quarterly. An old parser’s rejection of a newly assigned resource is therefore not proof that the phone is invalid.
Add rule_source, rule_version, normalized_at and transformation_reason to the migration table. Create an E.164 candidate only when the current rule, expected length and source provenance agree. The ECA’s numbering-service overview is a suitable first stop when checking who administers the resource and whether the governing material has changed.
Step 3: model migration as states, not pass or fail
A binary valid/invalid column hides too much. A practical queue uses at least five states:
- ready — explicit international notation, or a transformation supported by country provenance and a current rule.
- review-country — national-looking notation with no reliable evidence that the source is Ethiopia.
- review-length — suspected truncation, extension or unexplained characters.
- duplicate-candidate — the normalized phone matches another row, but the contact relationship remains unresolved.
- unrecoverable — scientific notation or truncation has destroyed information that cannot be recovered.
Only ready records enter the checker file. Keeping the other rows in a migration ledger is not a failure; it prevents damaged values from acquiring the appearance of a completed platform check.
Step 4: deduplicate the phone without merging the customer
Phone-level deduplication saves repeated checks. Contact-level merging changes business records and requires different evidence. A single normalized phone can therefore map to several contact_id values while it is checked only once. Orders, branches or named people remain separate until a human resolves the relationship.
The same rule applies when an output contains a mapped WhatsApp phone that differs from the submitted value. Treat it as a relationship requiring review, not permission to replace the CRM primary key. Number changes, formatting differences and shared business contact points are all plausible.
Step 5: make the TXT export reversible
AppShai accepts TXT input with one phone per line. Before upload, confirm that the TXT line count equals the number of unique ready phones, no line still contains scientific notation, no name or order column has leaked into the file, and every line can return to the migration ledger through batch_row.
batch_row | contact_id | phone_raw | phone_normalized | migration_state | rule_version
000184 | C-7712 | 09… | +2519… | ready | ET-2026-Q3
000185 | C-7713 | 8.71E+11 | [empty] | unrecoverable | ET-2026-Q3The illustration deliberately omits complete phone numbers. TXT contains only phone_normalized for ready rows. The migration ledger remains inside the company’s controlled environment.
Step 6: accept Full Format by field family
The WS Full Format Excel output can include phone, activity time, active days, gender, age, avatar, skin tone, avatar type, business status and mapped WhatsApp phone. “Full Format” names a defined field set; it does not promise that every cell is populated and does not include conversations, verified name, address, orders or income.
| Field family | Acceptance question | CRM treatment |
|---|---|---|
| Phone and mapped phone | Can the relationship be reconciled to the submitted row? | Send collisions to human review |
| Activity time and active days | Are check date, time zone and business window clear? | Store as an expiring observation |
| Avatar and avatar type | Are observed and unknown states distinguished? | Restrict access and retention |
| Gender, age and skin tone | What is missing, inferred and permitted? | Prefer governed aggregate research; never overwrite self-report |
| Business status | What account type was observed at check time? | Do not treat it as company due diligence |
Step 7: rerun a delta, not the whole archive
When a numbering rule or transformation changes, compare rule versions first. Identify the affected prefix, source system and batch, then reconsider only records that still have a valid business purpose and permission. This makes it possible to explain why a row moved from exception to ready without repeatedly processing the entire historical database.
Step 8: test the migration with counterexamples
A migration rule needs more than values expected to succeed. Before release, include duplicate country codes, a missing digit, an extension, a source-country conflict and a fixed line placed in a mobile cohort. The system should route each counterexample to the appropriate exception state rather than repair it to improve the ready rate.
Sample every migration_state and ask a second reviewer to classify the row from phone_raw, provenance and the written rule. Frequent disagreement means the specification is still ambiguous; improve the rule instead of widening automation.
The migration must also be reproducible. The same input with the same rule_version should produce the same candidate and state. Otherwise, processing a legacy CRM in stages creates a new inconsistency based on operator or run date.
The final handoff contains two connected deliverables: a migration report and the checker result. It reports raw rows, recoverable and unrecoverable records, exception reasons, unique normalized phones, duplicate relationships, unknown fields, mapping collisions and the rule version used. For an Ethiopia legacy CRM, that lineage is more valuable than a wide spreadsheet whose origins nobody can explain.
