Migration & data
Plumbing Software Migration Test Plan: Prove the Important Cases
A migration test should verify records, relationships, financial meaning, and repeat-import behavior—not just whether a file uploads. Use a small representative dataset, record expected outcomes, and keep unresolved cases visible before moving active work.
In this guide
Define success before running the import
Write down what must be preserved for the business to operate: customer identity, property links, active jobs, approved scope, invoice amounts, payment evidence, and important supporting records.
Separate native destination support from archival preservation. A field retained in an archive is not the same as a field available to technicians in the live workflow. Both may be acceptable for different information, but the distinction must be explicit.
Build a representative test set
| Test case | Expected review |
|---|---|
| Normal customer and job | Correct basic mapping |
| Customer with multiple properties | Relationships preserved |
| Long note or special characters | Content remains readable and complete |
| Leading-zero identifier | ID preserved as text |
| Missing optional field | No invented value |
| Missing required field | Clear rejection or review path |
| Duplicate source ID | Defined update or rejection behavior |
| Partial payment | Correct charge, payment and balance |
| Credit or refund | No invented payment history |
| Unsupported attachment | Explicit preservation or exception process |
Use fictional or appropriately protected test data in a suitable environment. Do not send customer notifications or payment requests accidentally during testing.
Record expected and observed results
Migration test case
Case ID: [reference]
Source file and row IDs: [references]
Scenario: [description]
Expected destination records: [types and relationships]
Expected amounts/statuses: [definitions]
Observed result: [evidence]
Pass / fail / needs review: [decision]
Issue owner and next action: [details]
Retest evidence: [reference]
A screenshot of a success banner is not enough evidence for a relationship or financial test. Inspect the relevant destination records and output documents.
Test a retry deliberately
Import the same controlled sample again only after understanding the supported behavior. Verify whether records are updated, ignored, rejected, or duplicated.
The important question is whether the same source identity produces the intended result on repetition. Do not assume a second successful upload is harmless.
Also test a corrected row. Confirm how the system distinguishes a correction to an existing record from a new customer or invoice.
Reconcile the entire sample
Count source rows, created records, updates, rejections, and exceptions. Every included source row should be accounted for through a documented outcome.
For financial cases, compare original charges, adjustments, payments, and balances separately. Equal grand totals can hide records assigned to the wrong customer.
Have the appropriate accounting owner review the financial test cases and any integration effects.
Run an operational walk-through
Ask the office to find a customer's history, open an active job, prepare a sample next step, and identify an invoice's payment evidence. Ask a technician to locate the information needed for an assigned visit using the intended permissions.
Do not claim that GoPlumber supports an imported field merely because it exists in the source file. Test the current destination behavior and record any limitation.
Sign off with known gaps
List what passed, what failed, what is preserved outside the live system, and what remains unavailable. Give each unresolved issue an owner and an explicit decision before cutover.
A credible test plan does not promise perfection. It provides evidence for the workflows that were actually checked and prevents untested assumptions from becoming live business dependencies.
Sources and editorial notes
Product and documentation references checked September 29, 2026. GoPlumber publishes this guide about its own product category. Examples and templates are original illustrative material, not customer case studies or market benchmarks. Confirm current vendor terms before acting.