How to migrate existing fiber network records

The short answer

Start with a preserved copy of your existing records. Inventory the sources, map their identifiers and relationships, then migrate a representative area for review. Check familiar fiber paths against the source records, resolve discrepancies, and agree on acceptance criteria before switching daily work. Train the people who will maintain the records and plan how changes made during the migration will be reconciled.

This guide draws on working discussions with OSPI Fiber co-founders Wade and Randy Anderson. It describes a review process, rather than a promise that every source format can be imported automatically. The scope, timing and commercial terms of an OSPI Fiber migration are agreed after reviewing the data.

1. What records should you collect first?

Begin with an inventory, not a conversion job. Identify where each part of the network is recorded, who maintains it and which copy is authoritative. A GIS map may contain cable geometry while a spreadsheet holds splice connections and a PDF records panel assignments. You need the relationship between those sources.

Use this inventory as a starting point:

Include records held outside the main system. Field crews, contractors and the NOC may each have updates that have not reached the master database. Record those gaps without assuming the newest file is automatically the most accurate.

2. How should you prepare a copy for migration?

Preserve the original export and its date. Work from a separate copy so cleanup and conversion decisions remain traceable. Record the source application, export settings, included layers or tables, coordinate reference information and the person who prepared it.

Agree on a private transfer method before sharing operational records. Remove credentials and personal information that the migration does not need. Use synthetic records for public examples and demonstrations; a copy of a live customer database is still customer data.

Keep an untouched baseline alongside a working version. If someone renames a cable or corrects a coordinate, log the change and its reason. This lets the reviewer distinguish a deliberate correction from information lost during conversion. A backup copy and a successful migration check serve different purposes; having the file does not establish that its relationships are correct.

3. What needs to survive a format change?

Preserve identity and connectivity as well as location. A cable line on a map does not, by itself, establish which strand is spliced to another strand or which panel port it reaches. Keep the tables, references and documents that carry those connections.

Create a field-mapping sheet for each record group. Include the source field, destination field, expected type or units, transformation rule and treatment of missing values. Keep a cross-reference when identifiers change. Review duplicate IDs, leading zeros, mixed naming conventions and references to records that are absent from the export.

Some formats carry geographic features and attributes; others hold drawings or tabular records. GeoJSON, for example, represents geographic features and their properties. RFC 7946 uses WGS 84 coordinates in decimal degrees. That standard does not establish an operator's fiber-connection model or guarantee that a particular application imports every property. Confirm the coordinate transformation and the destination's handling of fields and relationships. See the GeoJSON standard.

For CAD, check scale, units and geographic positioning before treating linework as a reliable map. For spreadsheets, define what each row means and how its cable, splice and port references connect to other records. Confirm source-specific conversion work with the migration team.

4. Why start with a representative area?

Choose a pilot that tests the work your team actually does. A simple straight cable may establish that geometry transfers, but it will not exercise every connection type. Include a familiar route, multiple cable sizes, a splice point, terminations and a few records that need clarification. Include splitters or other network elements when they matter to your operation and are in scope.

Before conversion, write down what the pilot should show. Ask an experienced operator to identify known endpoints and a route they can verify. Record the expected cable references and fiber assignments using the source records. Those expectations become a comparison set rather than a visual impression after import.

A pilot helps identify work and uncertainty. It is not proof that the whole network is clean. Agree which additional areas or unusual structures need review before expanding the scope.

5. How do you check a migrated fiber path?

Check the route from both the map and the connection records. Compare the asset inventory and counts for the agreed scope, then inspect selected records in detail. Counts can expose omissions or duplicates, but matching totals alone do not prove that fibers are connected correctly.

For each representative path, verify:

• The starting cable, fiber and termination port.
• The sequence of cables and splice points.
• Incoming and outgoing fiber assignments at each connection.
• The ending cable, fiber and termination port.
• Recorded lengths and units, with any differences explained.
• How spare, unconnected or unknown assignments are represented.

Synthetic example: a splice and its endpoint

The following invented records illustrate a review. They are not customer data or results from a completed migration.

For every discrepancy, record the asset, source reference, expected value, observed value, owner and resolution. Do not fill a missing connection with a guess simply to make a trace complete. An unresolved source record should remain visible as an issue to investigate.

6. What should the team approve before switching?

Agree on acceptance criteria before expanding the migration. The criteria should describe evidence the team can review: agreed records are present, identifiers resolve, representative paths reach the expected endpoints, and known exceptions have an owner and an accepted treatment.

Use this review checklist:

• The source inventory, export date and migration scope are documented.
• Coordinate system, units and field mappings have been checked.
• Cable, splice and termination references resolve for the agreed scope.
• Representative paths have been compared with source records.
• Differences in lengths, counts or assignments are explained.
• Missing or uncertain data is listed, assigned and explicitly accepted or corrected.
• The team has seen the reports or exports it needs for daily work.
• Operations users can find, interpret and update the records they are responsible for.
• Changes made in the source system during the pilot have a reconciliation plan.
• A named owner approves the switch and the fallback arrangements.

Keep this checklist with the review evidence. The appropriate acceptance criteria depend on the network and project; the checklist is a starting point, not an automated OSPI Fiber validation feature or a guarantee of complete accuracy.

7. How do you plan the switch to daily use?

A review copy is different from the current operational record. Decide which system remains authoritative during the pilot and how new construction, repairs and splicing updates will be captured. Otherwise, a well-reviewed pilot can be out of date before the team starts using it.

Agree a change cutoff or a controlled reconciliation process. Identify who will apply outstanding updates, rerun important checks and authorize the operational handover. Set a fallback plan that specifies the records and version the team would use, who can restore access, and how work performed after the switch would be retained. Do not assume that rolling back software also reconciles record changes.

Keep the original records and access arrangements available for the agreed review period. Discuss source-system export access and retention before ending an existing service. The amount of parallel operation and any service interruption should be planned for the specific project; neither should be assumed away.

8. What training keeps the records useful?

Teach the workflows that make the records useful every day. Start with finding a cable, understanding a splice, following a fiber path and checking its endpoint. Then practice the changes the team is responsible for recording, using examples they understand.

Randy has emphasized in our product discussions that regular use exposes record-quality problems and gives people a reason to keep the database current. Give office, field and NOC users a clear way to report discrepancies, and assign responsibility for reviewing and resolving them. A successful handover includes an update process, not just a demonstration.

For OSPI Fiber onboarding, you work directly with Wade and Randy. The initial conversation should identify the users, daily tasks and training needs. See the migration FAQ for the current approach to review and getting started.

Common migration questions

Can we migrate from OSPInsight, IQGeo or another fiber system?

Begin with a review of the records and exports available from that system. OSPI Fiber's early migration work has focused on OSPInsight and IQGeo data. Work involving another platform needs a source-specific assessment; familiarity with a vendor does not establish that every version or data model has a ready-made converter.

Can a map or a shapefile replace the splice database?

It depends on what it contains. Geographic cable features can be useful, but the migration also needs the fiber, splice and termination relationships used by the team. Review the accompanying attributes, tables and documents rather than assuming a map export contains all operational detail.

Can we review our records before committing to a switch?

Yes. Randy's approach is to work from a copy and walk through the migrated network with the operator. Use familiar routes and documented acceptance criteria to decide whether the result meets the team's needs. Agree the project terms separately.

How long does migration take, and what does it cost?

The source data, cleanup needs, network model and scope of review determine the work. Review a representative sample before agreeing on timing and pricing. Bring renewal dates, project deadlines and the operational workflows you need to preserve to that conversation.

Is a route export the same as a full network export?

No. A report or export of a selected path does not establish that every asset, relationship, attachment or history record can be exported. Identify the records and formats you need to retain and ask to see representative outputs before agreeing on scope.

Start with the records you have

Bring an inventory of your current systems, available exports, a familiar route and the questions your team needs answered. We can discuss a practical migration review without assuming that all records are complete or that every source needs the same work.

Book a migration conversation. No customer database upload is required through this website.