How to Migrate to Jobber for Electricians: 8-Week Electrical Software Migration Checklist

Some links on this page are affiliate links — I may earn a commission if you sign up, but it doesn’t change what I tell you about the product.

Migrating software is harder than choosing it. You’ll spend weeks wrestling with data formats, training your techs to stop using the old system, and validating that jobs, customers, and pricing landed correctly on the other side. The catch: vendors claim you can go live in two weeks. In real life, give it eight.

This guide walks you through a realistic migration timeline. I’ve watched three shops try this migration and two of them went back within 90 days—not because the new software was bad, but because they rushed the transition and lost control of their dispatch and billing in the process.

Why Migrations Fail: The Pattern

When migrations go sideways, it’s rarely the software. It’s almost always one of three things:

Data loss in translation. Your old system stores job history, customer notes, and pricing one way. The new system expects it another way. Some data doesn’t make the journey. You don’t notice until a tech is on site missing critical context—and your office manager is rebuilding customer records from email.

Training lag. You go live Monday with 12 techs on a new dispatch system. By Wednesday, three of them are calling the office 20 times a day because they can’t find their jobs or clock out correctly. Productivity tanks. Morale follows. Your office manager is now a help desk instead of running the business.

Parallel billing chaos. You run both systems at once to be safe. That’s sensible. What nobody mentions: you’re now entering data twice, syncing two QuickBooks connections, and reconciling discrepancies between systems. Your bookkeeper hates you. The process eats two weeks and bleeds money.

How to Avoid Becoming a Cautionary Tale

The eight-week plan below has a specific purpose: it spreads the load so that no single week breaks your operation. You’re running two systems at once, but not forever. You’re training in small groups, not all-hands. You’re validating data before you commit to it.

The only way this works is if someone owns it end-to-end. Not “IT responsibility” or “everyone pitches in.” One person. Ideally your office manager or dispatcher, because they own the dispatch workflow already and they’re the ones who’ll catch what’s broken first.

Pre-Migration: Weeks 1–2

Week 1: Audit and Plan

Start with data. Pull a complete export from your current system:

• All jobs from the last 24 months (completed, in-progress, cancelled)
• All customer records (addresses, phone, email, notes, credit limits)
• All rates and price book (service rates, labor rates, material markups)
• All tech profiles (names, certification data, specialties, rates)
• Recurring scheduling patterns (if applicable)

Then open the new system’s import documentation and ask the hard question: what do I have that they can’t take?

In real life, you’ll find:

• Custom fields your old system supports that the new one doesn’t (or won’t import directly)
• Date formats that don’t align
• Character limits on notes or descriptions
• Tech codes or naming conventions that don’t map

Don’t ignore these. Document them. For every gap, create a workaround: maybe you embed the custom data in a notes field, or you manually recreate a few critical fields in the new system, or you accept that historical data stays behind for reference and only bring forward active jobs.

Assign ownership. One person shepherds this whole process. They’re the single source of truth on what moved, what broke, and what stayed behind. That person should have access to both systems and enough authority to make decisions without three meetings.

Week 2: Test Import and Parallel Plan

Run a test import into a staging environment. Does it work? Does the data land where you expect? Check for:

• Customer names and addresses (especially multi-unit commercial)
• Job history (are dates preserved? are job statuses correct?)
• Pricing (did dollar amounts come through? did your tiered rates map correctly?)
• Tech assignments (do your techs show up in the new system with the right access level?)

If the import fails or data is corrupted, you stop here and fix it. Don’t push forward hoping to sort it out live.

Next, plan your parallel period. You’ll run both systems at the same time for 2–3 weeks. This is intentional. During that time your shop will:

• Dispatch sends all jobs into the new system
• Techs work the new system in the field
• But you also enter jobs into the old system for billing and QuickBooks
• At end of day, someone reconciles: do the systems match?

This is uncomfortable. It’s also how you catch problems before they cost you money. Pick an end date for parallel running that’s not negotiable. When it arrives, you stop using the old system cold. No exceptions.

Migration: Weeks 3–5

Week 3: Go Live with a Small Set

You don’t go live with your whole dispatch. You pick 2–3 techs. They run the new system for one full week while your other techs stay on the old system. This does three things:

1. Your dispatch has a safe failure zone. If the new system drops a job or loses data, it affects two techs, not eight. Damage is containable.
2. Your small group becomes your trainers. They find the dumb bugs (wrong buttons, missing fields, slow searches) before the rest of the team does. Weeks 4–5, they run the on-site training.
3. Your QuickBooks sync gets tested. One tech’s jobs flow through the new system and into your accounting. You validate that revenue is tracked, invoices are generated, and your bookkeeper isn’t digging through two databases to close the month.

During this week, your test group is hands-on supported. Someone from your office is available to troubleshoot. The new vendor’s onboarding team is on standby. You’re documenting every issue and the fix. This is your runbook for the next two weeks.

Week 4: Expand to 50% of Field Team

Second week of migration. Now 4–6 techs go live on the new system. Your original 2–3 are veterans now. They’re in the field helping the new group navigate. Your office still double-enters data into both systems.

This week is pure execution. You’re running two systems in parallel. Your dispatcher is tracking which jobs went to which system. Your bookkeeper is tracking which invoices came from where. It’s messy. It’s supposed to be. You’re validating that the new system holds up under real load before you commit all your work to it.

Watch for tech resistance. “I liked the old system better.” That’s normal. Some of it is real friction (the new system actually is slower at one task). Some of it is just discomfort with change. Acknowledge both. When it’s friction, fix it or work around it. When it’s just discomfort, move past it.

Week 5: Full Migration and Old System Sunset

All techs go live on the new system. No more parallel running. You’re fully committed.

This is the riskiest week. If something is broken in the new system, you only find out when it breaks your day. That’s why weeks 3–4 happened. You’ve already found and fixed the dumb problems. What’s left is unusual situations—a specific job type that doesn’t map, a multi-site customer, a payment reversal that the new system’s accounting doesn’t handle the same way.

On day one of week 5:

• All new jobs go into the new system only
• All updates to existing jobs go into the new system only
• Your last reconciliation between systems happens
• You archive the old system and lock it read-only

Have your new vendor’s support number on speed dial. Have your second-person (the one who backed up the primary owner) also briefed and available. One person on your office team should be dedicated to “support” that week—not regular dispatch, just troubleshooting.

Post-Migration: Weeks 6–8

Week 6: Validation and QuickBooks Sync

All data is now in the new system. Now you verify it landed correctly. Run these checks:

• Customer count. Do you have the same number of active customers in the new system as the old one?
• Job count. Do you see all of last month’s jobs in the new system?
• Price book accuracy. Pick 10 random jobs from week 5 and verify that labor and material rates match your actual rates.
• Tech data. Are tech rates, certifications, and assignment rules correct?
• QuickBooks sync. Is revenue flowing correctly? Are invoices generating with the right amounts? Is your bookkeeper happy?

If everything checks out, move forward. If you find gaps, you fix them now before they accumulate. You might need to manually adjust a few records or run a second import of specific data. That’s fine. The key is: you validate before the data rots in the system.

Week 7: Parallel Billing Closes

By now you’ve run one full month on the new system and your billing is syncing correctly. This week, you stop entering data into the old system. All billing, all invoicing, all revenue tracking flows from the new system only.

Your bookkeeper does final reconciliation: old system revenue vs. new system revenue for the month. They should match (minus anything you specifically excluded during pre-migration). If they don’t, you fix it.

Also this week: retire the old system. Archive it. Back it up. Lock it down. Your techs shouldn’t be able to log in. Dispatch shouldn’t be tempted to fall back. It’s done.

Week 8: Capture Learnings and Document

Migration complete. Now document what actually happened:

• What data didn’t move and why?
• What took longer than expected?
• What broke and how did you fix it?
• What would you do differently?

This matters for two reasons. One: if you have to do this again (new software in 5 years), you have a playbook. Two: you learn what the new system actually requires versus what the vendor claimed. That shapes how you use it going forward.

Common Blockers and How to Unblock Them

Data Format Issues: Custom Fields Don’t Import

Your old system has a field called “Certifications.” The new system doesn’t have a direct field for it. Solution: map it to a notes field or tag. You lose the structured data, but you keep the information. Decide in week 1 or 2, not during go-live. This is what the sales demo skips—the messy reality of legacy data that doesn’t fit neatly into the new product.

Tech Resistance: “I Want to Go Back to the Old System”

Some resistance is real friction. (The search function is genuinely slow. The mobile interface is clunky.) Some is just discomfort. Listen to the real friction. Fix it if you can. Work around it if you can’t. For the discomfort: acknowledge it, move past it. Give it two weeks. Most of it evaporates once the new process becomes routine.

Feature Parity Gaps: The New System Can’t Do What the Old One Did

You could schedule recurring jobs in the old system. The new one doesn’t have that feature. What now? Don’t wait for the vendor’s roadmap. Find the workaround: maybe you set a calendar reminder to create recurring jobs manually. Maybe you use a Zapier integration to automate it. Maybe you accept that this feature is gone and you manage it differently. Decide in week 1. Document it. Move on.

Syncing Issues: QuickBooks Isn’t Updating Correctly

You’ve got new jobs in the new system, but they’re not creating invoices in QuickBooks. First step: check the sync settings in both systems. Is the connection active? Is the mapping correct? (Are you sending “invoice” data or “estimate” data?) If the settings are right but the sync is still broken, this is a week 6 problem, not a week 5 problem. Don’t go live until the sync works in staging.

Billing Discrepancies During Parallel Running

You’re entering jobs in both systems. Week 3 jobs might be missing from the old system. Week 4 jobs might not sync to QuickBooks from the new system. Your bookkeeper sees a gap between systems and loses trust. Solution: run a daily reconciliation report during weeks 3–5. Both systems, side-by-side. Tag any discrepancies and resolve them same-day. Parallelism only works if you’re tracking what’s in each system.

The Catch

Migrations always take longer than vendors claim. Jobber will tell you go-live is a two-week project. It’s not. You’re running two systems in parallel. You’re training your techs and dispatch staff, who want to keep doing things the old way. You’re validating that data moved correctly. You’re fixing edge cases that nobody anticipated. That’s eight weeks minimum.

Also: something will break. Maybe it’s small (a report generates in the wrong format). Maybe it’s bigger (a tax calculation is off). The goal isn’t perfection. It’s catching broken things before they cost you money, and having a plan to fix them. The part nobody mentions in the vendor demo is how much of your time this actually consumes. Weeks 3–5 are rough. Your shop is running two dispatch systems at once, two billing systems, and two sets of paperwork. Expect 40 extra hours that month—minimum.

The 8-Week Checklist: What to Do Each Week

Weeks 1–2: Pre-Migration

• [ ] Export all data from current system (jobs, customers, rates, techs)
• [ ] Map old system fields to new system fields
• [ ] Identify data that won’t migrate and plan workarounds
• [ ] Assign one owner for the entire migration
• [ ] Determine parallel running period (2–3 weeks)
• [ ] Run test import into staging environment
• [ ] Validate imported data (customers, jobs, pricing, tech profiles)
• [ ] Fix any broken imports before proceeding
• [ ] Document all issues found and how they were resolved
• [ ] Brief your team on timeline and their role

Weeks 3–5: Migration

• [ ] Select 2–3 pilot techs for week 3 go-live
• [ ] Brief pilot techs on new system workflow (hands-on, not video)
• [ ] Week 3: Pilot goes live; all other techs stay on old system
• [ ] Document issues and fixes (becomes your runbook)
• [ ] Week 4: Expand to 50% of field team; maintain parallel billing
• [ ] Run daily reconciliation between systems (jobs, data, billing)
• [ ] Track tech feedback; separate real friction from discomfort
• [ ] Address critical friction issues within 24 hours
• [ ] Week 5: Full field team migration; old system becomes read-only
• [ ] Final reconciliation between systems before archiving

Weeks 6–8: Post-Migration

• [ ] Week 6: Validate all data in new system (customer count, job count, pricing, rates)
• [ ] Confirm QuickBooks sync is working correctly
• [ ] Reconcile new system billing vs. QuickBooks
• [ ] Fix any data anomalies before they accumulate
• [ ] Week 7: Stop entering data in old system; retire it
• [ ] Final billing reconciliation between old and new systems
• [ ] Archive old system; lock it read-only
• [ ] Week 8: Document lessons learned and workarounds
• [ ] Create a “new system playbook” for your team
• [ ] Schedule post-migration debrief with team

Data Audit Template: What to Export and Verify

From Your Current System:

• Customer records: count, fields (name, address, email, phone, notes, credit limit, service history)
• Jobs: count by status (completed, active, cancelled), date range, fields (job type, customer, tech assigned, dates, amounts)
• Pricing: all service rates, labor rates, material markups, package pricing
• Tech profiles: names, rates, certifications, specialties, call order
• Reports: monthly revenue, tech productivity, job cycle time

Import Checklist:

• [ ] Customer da
  

  Reference Guides & Resources

  This guide focuses on Jobber, so check the Jobber pricing breakdown to understand costs during migration. Our QuickBooks sync guide covers data handoff details. And if you haven’t yet compared all available platforms, start there.

  ta imported and count matches source system

• [ ] All job records imported with correct status and dates
• [ ] All pricing data imported; spot-check 10 random rates for accuracy
• [ ] Tech profiles imported with correct rates and permissions
• [ ] Payment history imported (if required by new system)
• [ ] Custom fields mapped or noted for manual entry
• [ ] Duplicate records identified and cleaned up
• [ ] QuickBooks sync tested and validated

Bottom Line (Revisited)

You have a real plan now. Eight weeks. One owner. Regular validation. Phased go-live. Parallel running where it matters. The whole operation is built around the fact that migrations are messy and that the best way to catch problems is to validate incrementally instead of hoping nothing breaks on day one.

The vendors will still tell you they’re simpler than this. They’re not. Your shop is worth protecting. Eight weeks is worth it.