Most fiber operators do not start with a purpose-built management platform. They start with spreadsheets. Excel is free, familiar, and flexible enough to hold splice details, cable inventories, and customer records for a small network. It works — until it doesn’t.
The transition point usually arrives quietly. A technician cannot find the right version of the splice file. Two people edit the same sheet and overwrite each other’s work. A capacity report takes three days to compile because the data lives in four different workbooks. A new hire asks a simple question about circuit connectivity, and nobody can answer it without driving to the closure.
That is when operators start looking at dedicated fiber management software. And that is when they discover the hardest part of the project is not choosing a platform. It is migrating the data.
This playbook outlines a practical, step-by-step approach to moving from spreadsheets to a fiber management platform without losing data, breaking connectivity records, or derailing field operations.
Why Data Migration Fails
Before outlining the process, it is worth understanding why migration projects fail. The patterns are consistent.
Garbage in, garbage out. Legacy spreadsheets contain duplicate records, inconsistent naming, missing coordinates, and orphaned entries. Importing that data without cleanup simply moves the problem into a new system.
No single source of truth. Different spreadsheets hold conflicting versions of the same record. Nobody knows which one is correct.
Underestimated scope. Teams assume migration is a technical import task. In reality, it is a data quality project that happens to end with an import.
No field validation. Spreadsheet data is rarely verified against the physical network. Migrating unverified data produces a digital map that looks complete but does not match reality.
Big bang cutover. Attempting to migrate the entire network in one weekend, with no fallback plan, invites disaster.
The playbook below addresses each of these failure modes.
Phase 1: Prepare the Ground
Step 1: Define What “Migrated” Means
Before touching any data, define success. A migrated record should be complete, accurate, and usable. For a cable, that means a unique ID, fiber count, route geometry, and installation metadata. For a splice, it means incoming and outgoing strand IDs, closure reference, tray position, and loss value.
Write these definitions down. They become the acceptance criteria for every record in the new system.
Step 2: Inventory Your Data Sources
List every place fiber data currently lives:
- Splice spreadsheets
- Cable and route inventories
- Customer connection logs
- Closure and cabinet records
- OTDR test results and loss measurements
- CAD drawings and as-built PDFs
- Google Earth or QGIS files
- Paper field notes and binders
- Contractor handover packages
For each source, note the owner, the last update date, and the approximate record count. This inventory reveals the true scope of the project and identifies which sources are authoritative.
Step 3: Assign a Migration Owner
Migration needs a single accountable owner. This is usually an operations manager or network engineer who understands both the field reality and the business requirements. The owner is responsible for decisions about data conflicts, priorities, and timelines.
Step 4: Choose a Pilot Area
Do not migrate the entire network at once. Select a pilot area — a single route, a neighbourhood, or one central office’s serving area — that is representative of the wider network. The pilot validates the process, surfaces problems early, and builds confidence before the full rollout.
Phase 2: Clean and Normalize the Data
This is the longest phase of the project. Budget for it accordingly.
Step 5: Consolidate into a Staging Workbook
Copy all relevant data into a single staging workbook with clearly defined tabs for each entity type: cables, strands, splices, closures, structures, sites, and customer connections. Do not edit the originals yet. The staging workbook is a working copy where consolidation and cleanup happen.
Step 6: Standardize Naming Conventions
Inconsistent naming is the most common data quality problem in fiber spreadsheets. Before migration, define and apply a standard for:
- Cable IDs (e.g., region-route-sequence)
- Closure IDs
- Structure IDs (poles, handholes, pedestals)
- Site IDs (central offices, buildings, customer premises)
- Strand identifiers (cable ID plus position)
- Circuit identifiers
Apply the standard across the entire staging workbook. This step alone often reveals duplicates and missing records.
Step 7: Deduplicate Records
Search for duplicate entries. Common sources include:
- The same cable entered twice with slightly different names
- Splices recorded in two different workbooks
- Closures listed under both an old and a new ID
For each duplicate, decide which record is authoritative. Merge the data where appropriate and delete the rest. Document every decision.
Step 8: Fill the Gaps
Identify missing mandatory fields. Common gaps include:
- Missing GPS coordinates for closures and structures
- Missing splice loss values
- Missing strand colour codes or buffer tube positions
- Missing installation dates or contractor references
Some gaps can be filled from other sources, such as CAD drawings, contractor handover packages, or test reports. Others require field verification.
Step 9: Validate Connectivity
Connectivity is the hardest part of any migration. A splice record is only meaningful if both the incoming and outgoing strands exist and are correctly identified. Work through each splice and confirm that:
- Both strands exist in the cable inventory
- Both strands are referenced with the correct cable ID and position
- The closure referenced in the splice record exists
- The tray and cassette positions are plausible
Inconsistent connectivity is the leading cause of post-migration frustration. Fix it in the staging workbook, not after import. If your network uses passive splitters, this is also the moment to confirm splitter ratios and port assignments survive the move — the same relational checks apply, and fiber splitter and cabinet management covers how those records are structured once they live in a proper data model rather than a merged cell.
Step 10: Verify Against the Field
Select a sample of records — typically 10 to 20 percent of the pilot area — and verify them physically. Confirm that the cable routes, closure locations, and splice details in the staging workbook match what is actually installed. Field verification catches errors that no amount of spreadsheet reconciliation will find.
Phase 3: Prepare for Import
Step 11: Map Source Fields to the Target Schema
Every platform has its own data model. Obtain the import specification from your chosen platform and map each field in the staging workbook to the corresponding target field. Document any transformations required, such as converting coordinate formats or splitting combined fields into separate attributes.
Step 12: Build a Test Import
Import a small subset of the cleaned data into a test environment. Verify that:
- All mandatory fields are populated
- Relational links (splices to strands, closures to structures) are correctly established
- Coordinates appear in the right location on the map
- No duplicate records were created
Use this test to refine the field mapping before the full import.
Step 13: Define a Rollback Plan
Even with careful preparation, imports can fail. Define a rollback plan before the production import:
- Keep the staging workbook and all originals intact
- Take a snapshot of the target system before import
- Document the steps required to revert if needed
A rollback plan is not pessimism. It is professional risk management.
Phase 4: Execute the Migration
Step 14: Import in Batches
Import the data in logical batches — by route, by region, or by entity type — rather than all at once. Batch imports allow you to verify each stage before proceeding. Entity types typically migrate in this order:
- Sites and structures
- Cables and routes
- Strands
- Splices and connectivity records
- Customer connections and circuits
- Test results and attachments
Step 15: Validate After Each Batch
After each batch, run validation checks:
- Record counts match the staging workbook
- No records are orphaned
- Connectivity traces successfully from endpoint to endpoint
- Map geometry is correct
Document the results of each validation. This documentation becomes part of the migration record and supports future audits.
Step 16: Reconcile Discrepancies
Inevitably, some records will fail validation. Common causes include malformed coordinates, duplicate IDs created during import, or missing referenced records. Resolve each discrepancy in the staging workbook and re-import the corrected records. Do not leave known errors in the production system.
Phase 5: Stabilize and Hand Over
Step 17: Freeze the Spreadsheets
Once the production system is live and validated, freeze the legacy spreadsheets. Make them read-only. Announce that the new platform is the single source of truth and that no further updates will be accepted in spreadsheets.
This step is essential. If both systems remain active, the data will diverge within weeks.
Step 18: Train the Team
Training should cover:
- How to search for a cable, strand, or closure
- How to document a splice
- How to trace a circuit
- How to update a record after field work
- How to export reports
Role-specific training works better than one-size-fits-all sessions. Field technicians need different skills than engineers or managers. This is also where a written reference pays off: MapItRight’s resource library collects walkthroughs and guides that new hires can follow without pulling a senior engineer off the job.
Step 19: Run a Post-Migration Audit
Two to four weeks after go-live, audit a sample of records against field conditions. Check for:
- Records that were updated incorrectly
- Records that were not updated at all
- New work that was documented outside the system
Address findings immediately. Early correction prevents the documentation drift that undoes the value of the migration.
Step 20: Establish Ongoing Data Governance
Migration is a one-time project. Data quality is an ongoing discipline. Establish governance rules:
- Who can create, edit, and delete records
- What validation rules apply at the point of entry
- How often audits are performed
- How change histories are reviewed
Common Pitfalls and How to Avoid Them
| Pitfall | Prevention |
| Skipping the cleanup phase | Budget 50–70% of project time for data cleaning |
| Migrating everything at once | Use a pilot area and batch imports |
| Ignoring connectivity validation | Validate every splice against its referenced strands |
| No field verification | Physically check a sample before go-live |
| Keeping spreadsheets active | Freeze legacy files on go-live day |
| Inadequate training | Provide role-specific training and reference guides |
| No audit trail | Confirm the platform records who changed what and when |
| No rollback plan | Snapshot the system and keep originals intact |
Choosing a Platform That Supports Migration
The migration is easier when the platform is designed for it. Look for:
- Documented import specifications with clear field mappings
- Bulk import tools for CSV or API ingestion
- Relational integrity checks that catch orphaned records
- Data validation at import that flags errors before they enter the system
- Export in portable formats so you are never locked in
- An API for programmatic migration and future integrations
- Clear audit trails to verify what was imported and when
Platforms built around strand-level connectivity and real-time field capture are structured to accept clean, normalized data and validate connectivity on import. For teams planning the transition, moving fiber inventory off spreadsheets describes how that import workflow is handled in practice — covering staging, validation, and connectivity checks rather than a blind bulk upload.
Conclusion
Migrating from spreadsheets to fiber management software is not primarily a technology project. It is a data quality project. The platforms can import records in hours. The months are spent consolidating, standardizing, deduplicating, and validating the data that has accumulated over years of spreadsheet improvisation.
The operators who succeed are the ones who plan for that reality. They pick a pilot area, clean before they import, verify against the field, import in batches, and freeze the old system on day one. The result is not just a new platform. It is a trustworthy operational record that finally matches the network in the ground.