Every comparison page on this site quietly assumes you can actually switch from your current system. That assumption is doing real work, and it deserves a real page. This is the honest version of what happens when you move from ServiceTitan, Housecall Pro, Jobber, FieldEdge, Workiz, Service Fusion, FieldPulse, or a stitched-together Zapier stack to Dino AI Hub — what we do, what you do, what takes time, what doesn't migrate cleanly, and what happens if you ever decide to leave.
We are not going to tell you the migration is seamless. Moving a working trade business from one operations system to another is real work — your customer records, job history, equipment service records, invoices, integrations, phone numbers, and the institutional knowledge in your office staff all have to make the trip. The shops that pretend otherwise are the same ones that promise three-day implementations and deliver six-month nightmares.
What we will tell you is that the work is well understood, the phases are predictable, and the part that's hardest for most shops — the data extraction, mapping, validation, and reload — is handled by our onboarding team rather than by your office manager working nights and weekends. The shop's job during migration is to make decisions about how their operations should work going forward, not to learn new software architecture under deadline.
What "migration" actually means
For a typical 4-to-20 truck trade shop currently running on a cloud FSM platform, migration to Dino AI Hub involves moving roughly seven categories of data and operational state:
Customer records — names, addresses, contact information, service history flags, tags, custom fields, account notes, billing preferences. Usually the cleanest category to migrate.
Property and equipment records — service addresses (often distinct from billing addresses), equipment installed at each property, serial numbers, install dates, warranty status, service history per piece of equipment. Critical for HVAC, plumbing, electrical, and appliance repair shops.
Job and work-order history — past jobs with their dates, technicians, work performed, notes, and outcomes. The depth varies dramatically by source platform.
Pricing and pricebook data — your service catalog, materials catalog, good-better-best tiers, and the structured data that makes mobile estimating work. Often the most labor-intensive category because formats vary widely.
Invoices, payments, and financial records — historical invoices, payment status, outstanding balances, accounts receivable. The clean financial trail your books depend on.
Operational configuration — service area definitions, tech skills and certifications, dispatch rules, automation triggers, customer communication templates.
Integrations and phone numbers — connections to QuickBooks, payment processing, calendar systems, Meta and Instagram for marketing, and the actual phone numbers your customers call. Phone number porting is its own coordinated process.
Not all of these migrate the same way. Some flow through cleanly via the source platform's data export tools. Some require API access. Some need manual reconstruction. The migration playbook is specific to which platform you're coming from, which is why the discovery phase exists.
The four phases
Every migration follows the same four phases. The duration of each varies by source platform and shop complexity; the structure does not.
Phase 1 — Discovery (typically 3-7 days)
We start with a discovery call walking through how your shop actually operates day-to-day — your dispatch flow, your pricebook structure, your customer types, your service area, the workflows that make your specific operation work. This is not training. It's us learning your business so the appliance gets configured for how you work rather than for some generic trade-business archetype.
After the call, you export your data from your current platform using the platform's built-in CSV export tools. Every major FSM platform supports this — Housecall Pro, Jobber, ServiceTitan, FieldEdge, Workiz, Service Fusion, FieldPulse, mHelpDesk, ServiceM8, all of them — and we give you a step-by-step checklist of exactly what to export and where to find it in your specific platform. You upload the files to us through a secure transfer. We don't need credentials, API keys, or access to your live system.
At the end of Discovery, you get a written migration plan: what data we'll move, what we'll leave behind, where we expect data quality issues, what your cutover date can realistically be, and what your appliance configuration will look like on day one.
Phase 2 — Migration (typically 1-3 weeks)
We receive your exported data files, map them to Dino AI Hub's schema, validate them, and load them onto your appliance — which by this point has been provisioned and is sitting in our facility being configured.
This phase happens largely without your involvement. You may get a few questions when our team finds ambiguous data — customer records with conflicting addresses, equipment records missing serial numbers, recurring jobs that aren't clearly scheduled. These are the data-quality issues your current system has been quietly carrying for years; the migration is a forced reckoning with them.
Toward the end of this phase, we do a test cutover — a small subset of your operations (one tech, a handful of customers) running on the new appliance in parallel with your current platform. You verify that the data looks right, that the workflows make sense, that the customer portal renders correctly with your branding.
Phase 3 — Parallel operation (typically 1-2 weeks)
The appliance ships to your office. Your team is trained. For one to two weeks, both systems run in parallel: existing open work continues to be tracked in your old platform; new customers, new calls, and new jobs go into Dino AI Hub.
This is the period where your office staff actually learn the new system on real work without the pressure of the old system being switched off. We're there for this whole period — same-day responses to questions, screen-shares to work through any workflow that doesn't feel right, configuration adjustments based on what your team actually needs.
During parallel operation, we also coordinate phone number porting if applicable. Carrier-side porting typically takes 7-14 business days; we schedule it so the numbers transfer at cutover, not before.
Phase 4 — Cutover (typically 1 day)
You stop using your old platform. New work goes only into Dino AI Hub. The phone numbers ring on the appliance. We're on standby for the first 48 hours in case anything needs adjustment.
Open work that was in your old platform on cutover day either gets completed in the old platform (the cleanest option for in-flight jobs) or gets manually moved into Dino AI Hub (the cleaner option for scheduled-but-not-started work). The migration plan from Phase 1 tells you which is which.
You stop paying the old platform's subscription at the end of its current billing cycle.
Per-platform notes
How the migration actually works varies by what you're coming from. The notes below cover the seven FSM platforms most of our incoming customers are on.
From ServiceTitan
ServiceTitan has the deepest data structure of any FSM platform in the trades, which is a double-edged sword for migration. The customer, property, equipment, invoice, and job data exports cleanly through ServiceTitan's built-in CSV export tools and the Reports module — you'll typically pull eight to twelve report exports from the platform. The marketing-attribution data, custom reports, and any business logic encoded in ServiceTitan's automation builder will not transfer one-to-one and either gets reconstructed in Dino AI Hub or replaced with equivalent local workflows. Your ServiceTitan multi-year contract is the operational constraint here — if you have time remaining, we structure cutover to align with renewal. Pricebook migration is meaningful work; ServiceTitan pricebooks are sophisticated and your version of "good-better-best" gets rebuilt in Dino's format rather than copied verbatim.
From Housecall Pro
HCP supports CSV export of customers, jobs, estimates, invoices, and the price book through the platform's Reports and Account settings — the export tools are mature and shop owners can pull these themselves without involving HCP support. Customer records, job history, invoices, and the price book all migrate without major structural issues. The HCP Assist or CSR AI call data does not transfer; those calls live in HCP's cloud. If you've built workflows around HCP's marketing automation features, those get rebuilt in Dino's equivalents. HCP has no contract, so cutover timing is whenever your shop is ready.
From Jobber
Jobber's CSV export through the Reports section is mature and well-supported — clients, properties, jobs, quotes, invoices, and payment history all export cleanly through the platform's built-in tools. Customer, property, job, quote, and invoice migration is straightforward. Jobber's recurring-job and route-optimization configurations need to be reconstructed in Dino's scheduling system; the underlying data moves but the operational logic is rebuilt to match how Dino handles recurring work. If you're on the Plus tier using AI Receptionist, the call recordings stay in Jobber's cloud — only the customer interactions captured as job records make the trip.
From FieldEdge
FieldEdge supports CSV export through its Reports section — customer, equipment, work order, and invoice exports are standard. The QuickBooks Desktop integration is the migration's central complication. The customer, equipment, and job data migrates from FieldEdge through its export tools. The QuickBooks side needs separate handling — we coordinate with your bookkeeper to either re-establish QBD sync from Dino AI Hub or transition to QuickBooks Online (which Dino AI Hub also supports natively). Your customizable good-better-best pricebooks rebuild in Dino's format. FieldEdge contract terms vary; we work around them rather than against them.
From Workiz
Workiz supports CSV export of clients, jobs, invoices, and inventory through the platform's admin tools. The interesting piece is the integrated phone system — Workiz handles VoIP and call recording inside the platform, while Dino AI Hub does the same locally on the appliance. The phone numbers port; the historical call recordings stay in Workiz's cloud (typically not exportable through standard tools — if preserving them matters, we discuss options during Discovery). Genius Answering call data has the same constraint. Customer, job, and invoice data exports without unusual issues.
From Service Fusion
Service Fusion supports CSV export through its reporting tools. The flat-rate unlimited-user model means your data export typically covers more user accounts than other platforms — every dispatcher, office person, and tech has their own login and history. We consolidate the user data during migration so Dino AI Hub's permission structure matches your actual organizational chart. QuickBooks Online and Desktop integrations carry over. ServiceCall.ai call data stays in Service Fusion's cloud. A note on Service Fusion specifically: public reviews mention occasional difficulties getting complete data backups from the platform — we typically run exports in batches and verify completeness during the validation step rather than assuming a single export captures everything.
From FieldPulse
FieldPulse supports CSV export of customers, jobs, invoices, and estimates through its admin interface. ClearPath workflow configurations rebuild as Dino's job-stage workflows (the underlying logic transfers; the specific button-by-button setup is reconstructed). Operator AI call data stays with FieldPulse. The QuickBooks Online integration carries over. FieldPulse contracts run annually; we schedule cutover toward renewal when possible.
From a Zapier or Make.com stack
Coming off a stitched-together SaaS stack — CRM in one tool, scheduling in another, invoicing in a third, phone system separate — is its own migration shape. You export from each tool individually using whatever each tool's CSV/Excel export supports, we reconcile the data (matching the customer record in the CRM to the job records in the scheduling tool to the invoices in the invoicing tool), and load the consolidated dataset into Dino AI Hub. This often surfaces data quality issues that the integrations were quietly masking — duplicates, mismatched names, customers in one tool but not another. The migration is sometimes the first time the shop sees its customer base as a single consolidated set.
From spreadsheets and QuickBooks alone
For shops not yet on a real FSM platform, migration is simpler in some ways (less data, fewer integrations) and harder in others (the data is in inconsistent formats and often incomplete). You export the customer list from QuickBooks, send whatever customer-record spreadsheets you have, and we use Discovery to surface the operational knowledge that lives only in your head. This category of migration is the cleanest opportunity to start fresh.
What doesn't migrate cleanly
The honest part. Five categories of data that typically don't transfer well from a cloud FSM platform to any new system, including Dino AI Hub:
Call recordings from cloud-based phone systems. Calls handled by Workiz Genius Answering, Jobber AI Receptionist, HCP CSR AI, Service Fusion ServiceCall.ai, FieldPulse Operator AI, or any standalone AI receptionist (Rosie, Goodcall, Smith.ai) live in the vendor's cloud. These typically can't be exported through the standard CSV/admin tools — the recording metadata sometimes can, but the audio files themselves usually can't. If preserving call recordings matters for compliance or business reasons, we discuss it during Discovery; in most cases the practical answer is that historical recordings stay with the old vendor and new recordings handled by Dino AI Hub live on your appliance going forward.
Email and SMS conversation history within the FSM platform. Some platforms keep a full thread history per customer; some don't. Where the source platform has reliable export, we move the history. Where it doesn't, customer communication starts fresh in Dino AI Hub on cutover day — the customer record carries the context, but the specific messages don't.
Marketing attribution data. ServiceTitan and a few other platforms track which calls came from which marketing source. Those attribution chains typically don't survive a migration to any new platform. If marketing attribution matters to your operation, we discuss what to preserve in Phase 1.
Custom reports and dashboards built in the source platform. The underlying data migrates; the report definitions don't. Your standard reports rebuild in Dino AI Hub. The reconstruction is usually faster than the original because Dino's reporting works against a unified local database rather than a multi-tenant cloud one.
Open work in flight at cutover. Jobs that are scheduled, dispatched, but not yet complete on cutover day need to be either completed in the old platform or manually moved. Most shops choose to finish open work in the old platform during the parallel-operation phase, then cut over with a clean slate. This is operational, not technical — but worth planning.
What it costs
White-glove migration is included in the appliance purchase for shops with typical migration complexity — meaning a single source FSM platform, fewer than ~5,000 historical customer records, standard data structures, and a cutover window aligned with our scheduling.
Complex migrations — multiple source systems, very large historical datasets, custom integration reconstruction, accelerated timelines — are scoped separately during Discovery and quoted before any work begins. Most migrations fall into the included tier.
We do not charge subscription fees for the operations software running on your appliance after you own it, including any post-migration support. That said, certain pass-through costs (carrier porting fees from your old phone provider, any export fees imposed by your old FSM vendor) are not within our control.
What happens if you change your mind
This section is on this page because it's the question every serious buyer asks and most vendors avoid answering.
If you decide six months or two years after migration that Dino AI Hub isn't right for your shop, here is what happens:
- You keep the appliance. It's hardware you own.
- You keep the data. All of it. Customer records, job history, invoices, call recordings, equipment service records. It lives on your machine; we don't have a copy to hold over you.
- You can export the data to standard formats. CSV, JSON, SQL dump — whichever fits the next system you're moving to. We document the data schema so any competent developer (or competing FSM vendor's onboarding team) can ingest it.
- You stop receiving software updates for the operations layer after you stop being a customer, but the appliance continues to function on whatever version it was on when you left.
- There is no subscription to cancel because there was never a subscription.
This is the part of the architecture that matters in five years even if you never use it. With cloud FSM, leaving means a data extraction battle — pulling your records out of a vendor whose business model depends on switching costs being high. With Dino AI Hub, the data is already physically yours. The exit path is the same path your accountant takes when she opens the appliance's database.
We mention this not because we expect anyone to leave, but because the architectural commitment matters before you sign, not after.
How long the whole thing takes, honestly
Realistic end-to-end timelines:
- Solo to 5-truck shop coming from HCP, Jobber, Workiz, or simple Service Fusion: typically 3-5 weeks from discovery call to fully cut over
- 5-15 truck shop coming from ServiceTitan, FieldEdge, FieldPulse, or complex Service Fusion: typically 5-8 weeks
- 15-30 truck shop with multiple integrations and significant historical data: typically 8-12 weeks
- Shop coming off a Zapier stack with data scattered across 5+ tools: add 2-4 weeks for data reconciliation
- Custom or commercial-trade contractor with non-standard workflows: scoped during Discovery, typically 10-16 weeks
The longest part of every migration is parallel operation, not the technical work. The data migration itself usually completes in days; the technical complexity of moving records is real but bounded. The unbounded part is your team learning to run the business on the new system, and that takes whatever time it takes.
When not to migrate
Some operational windows are wrong for any major systems change. Don't start a migration if any of these is true:
- You're in the middle of your busiest season. HVAC in July, plumbing during a regional freeze, heating in the first cold snap. Schedule migrations for shoulder seasons (March/April or September/October for most trades).
- You're in the middle of an acquisition, sale, or major restructure. Operational changes compound badly. Finish one transition before starting the next.
- Your owner is checked out of the project. Migrations that aren't driven by the owner fail. If the office manager is interested but the owner is half-committed, postpone.
- You're a brand-new business still finding your operational shape. Pick a simple cloud platform, run for 18-24 months until your workflows are stable, then revisit the architecture question.
- You don't have a clear cutover date in mind. Open-ended migrations drift. Pick a date during Discovery and work backward.
If any of the above applies, the right answer is "not yet" rather than "this is the wrong system." We'd rather wait three months for the right window than start migration during the wrong one.
A few questions we get often
Will my customers notice anything during the migration?
The phone numbers ring as they always did. The invoices look like yours (rebranded into Dino's templates if you want, or matching your existing design). The customer portal at {yourshop}.alltrix.ai goes live at cutover. Most shops report customers don't notice until they see the portal link in a follow-up email.
Why do you have me export the data rather than connecting to my current platform's API? Two reasons. First, you stay in control — you decide exactly what gets exported and shared, and we never touch your live production system. Second, every major FSM platform supports CSV export through its built-in tools, so there's no operational reason to involve API credentials and the security exposure that comes with them. The export takes most shop owners an hour or two with our checklist. For very large datasets or unusual platforms where standard exports are incomplete, we discuss alternatives during Discovery.
Do I have to retrain my office staff? Yes, but most of it happens during the parallel-operation phase on real work, not in a classroom session. Our team does the initial training on the appliance, and your staff are functional on it within a few days. Confident takes a few weeks of real use.
Can I run Dino AI Hub alongside my old system permanently as a backup? No. Running two operations systems permanently creates data fragmentation and confused customers. The parallel-operation phase is bounded for a reason. After cutover, your old platform is paused or canceled.
What if something breaks on the appliance after migration? The appliance is a sealed Mac with software updates included. Hardware failures are covered under our standard warranty (separate page details). For day-to-day support after migration, you have direct contact with the same team that handled your migration — not a tier-one support queue.
Can I migrate without buying the appliance first? The Discovery phase is no-commitment; you can complete a discovery call and get a written migration plan without buying anything. The actual data mapping and configuration work begins after the appliance purchase.
The conversation we'd suggest
If you're seriously considering a switch, the right next step is a discovery call. We'll look at your current platform, your shop size, your integration setup, and your operational calendar, and tell you honestly when the migration window makes sense and what it looks like. If the answer is "not yet for these specific reasons," we'll say so.
[CTA: Schedule a discovery call → demo booking]