How American Bath & Shower Moved Roughly 700,000 Records from LeadPerfection into HighLevel

TL;DR

Customer: American Bath & Shower (bathroom remodeling contractor, Florida. Tub-to-shower conversions and bathroom renovations, sold and installed in-house.)

The Move: LeadPerfection to HighLevel. Customers, leads, jobs, appointments, calls, notes and documents, rebuilt into a pipeline structure rather than copied table-for-table.

The Scope: Roughly 700,000 records across 32 source tables. Over 470,000 call records, close to 89,000 notes, around 40,000 documents, roughly 37,000 leads, roughly 33,000 customers and over 21,000 appointments. Six years of sales and installation history.

The Roadblock: LeadPerfection is a legacy on-premise CRM built for home-improvement contractors. There is no bulk export API. The only route to the data was its SQL Server database directly, with a separate cookie-authenticated web session for the handful of objects the database did not expose cleanly.

The Outcome: Every customer, lead and job in scope migrated to HighLevel, routed into the right pipeline and stage, with original LeadPerfection dates preserved in dedicated fields rather than lost to HighLevel's own timestamps.

By the Numbers

• Call records migrated: over 470,000
• Notes migrated: close to 89,000
• Documents migrated: around 40,000
• Leads migrated: roughly 37,000, of roughly 37,000 in scope
• Customers migrated: roughly 33,000, of roughly 33,000 in scope
• Appointments migrated: over 21,000
• Job payment records: close to 4,000
• Job milestones: over 3,700
• Jobs migrated: roughly 1,800, of roughly 1,800 in scope
• Source tables read: 32
• Data span: six years of sales and installation history

The Challenge: A CRM With No Way Out

American Bath & Shower sells and installs bathroom remodels in Florida — tub-to-shower conversions, full renovations, the sort of work that starts with a lead from a home show and ends with an installation crew on site. Their entire commercial process lived in LeadPerfection: a CRM built specifically for home-improvement contractors, and one that most integration tooling has never heard of.

That specialisation is the problem. LeadPerfection models the contractor's world properly — leads, set and confirmed appointments, jobs, production calendars, milestones, payments, branches, dispositions, sales reps and setters as distinct roles — and it holds all of that in a relational schema of its own design. What it does not have is a modern export path. There is no bulk API to call, and no documented extract that produces the whole picture with its relationships intact.

Three things followed from that:

• The data had to be read at the database level. Not through an integration, not through a CSV export from the interface, but by connecting to LeadPerfection's SQL Server tables and reading them directly. Thirty-two tables, each with its own key structure and its own relationship to the others.
• The destination has a completely different shape. HighLevel thinks in contacts and opportunities moving through pipelines. LeadPerfection thinks in customers, leads and jobs with a production calendar attached. There is no field-to-field mapping between those two worlds; the migration had to decide what a LeadPerfection record means in HighLevel and build accordingly — the same structural question behind any move into HighLevel, only with no vendor-supplied importer to start from.
• HighLevel stamps its own dates. A contact created during the migration is created today, as far as HighLevel is concerned. For a business that measures itself on how leads age and how long jobs take, a CRM where every record was created on the same Tuesday is useless.

I dealt with several companies and freelancers, and I asked everyone the same question. What made me go with ClonePartner is that they knew exactly what I needed without me having to fully elaborate, and knew exactly how they were going to handle it. That type of confidence was reassuring.

The ClonePartner Solution: Read the Database, Rebuild the Process

Extract at the source of truth. Each of the 32 tables was read directly from SQL Server and staged, with explicit column selection where the schema needed it — note bodies, for instance, had to be cast out of their native type before they could be read reliably. Indexes were created on the staged data as it landed, keyed on the relationships the push would later need: a lead to its customer, a job to its lead, an appointment to both. A separate cookie-authenticated web client covered the few objects the database did not expose usefully, throttled deliberately so it never behaved like a scraper against the customer's own system.

Rebuild the sales process as pipelines. This was the core of the work. Rather than dropping every lead into one list, a routing engine decided — per lead, from its disposition, its date, its assigned sales area and its product — which of five HighLevel pipelines it belonged in and which stage it had reached: the main CRM pipeline, a production pipeline for work in progress, a nurturing pipeline for leads not yet ready, a rehash pipeline for leads to be re-approached, and a completed-jobs pipeline. Won and lost states were derived from LeadPerfection's own disposition codes rather than guessed, and dispositions that meant "appointment only" were routed differently again.

Our owners needed the most recent leads moved over first so the team could keep working them without missing anything. That was a deal breaker for them. ClonePartner understood what mattered and delivered.

Preserve the real dates. Original LeadPerfection creation dates were written into a dedicated custom field on every migrated lead and contact, in a pass that ran after creation. HighLevel's own timestamps still show the day of the migration; the field next to them says when the lead actually arrived, and that is the one the business reports on.

Map people, not just records. Employees became HighLevel users, and each lead, job and appointment kept its original owner. LeadPerfection distinguishes setter, confirmer, verifier, promoter and sales rep as separate roles on the same record — a distinction that exists because different people are paid on different ones — so those were carried across rather than flattened to a single owner.

Documents through object storage. Around 40,000 files were staged in object storage first and uploaded to HighLevel afterwards, in bounded batches, with the file type set correctly from the extension so a PDF arrives as a PDF. HighLevel caps files per record at 50, so the per-entity limit was enforced on our side rather than discovered as a wall of rejections.

The Results

The migration ran over roughly four weeks. Jobs and customers were pushed across the first three, and leads in a final two-day run.

All three finished complete: every job, every customer and every lead in scope is in HighLevel. Around them sit the call history, notes, appointments, documents and payment records that give each one its context — over 470,000 call records alone, which for a business that lives on phone follow-up is the difference between a contact record and a relationship.

What American Bath & Shower has now is their commercial process running in a platform with modern automation and messaging, holding six years of history that would otherwise have stayed locked in a database nobody wanted to keep running.

They responded within 24 hours, and not just the account lead, they copied in the actual developer. A lot of times it's not about meeting the deadline precisely, it's about the ability to communicate and respond. ClonePartner checked all the boxes there.

What Made This Migration Different

For teams planning a move off a specialist industry CRM, three details from this project are worth noting:

• "No API" is not the same as "no migration". Vertical CRMs built for one trade often predate the idea of an integration platform, and the absence of a documented export is the normal case rather than the exceptional one. The database underneath is still a relational schema, and reading it directly — with the customer's cooperation and a copy rather than the live system — is frequently the shortest honest path. The work moves from calling endpoints to understanding a schema, which is a different skill but not a harder one.

• A pipeline migration is a process decision, not a field mapping. The hard question here was never which column goes where. It was which of five pipelines a four-year-old lead with a particular disposition belongs in, and whether it counts as lost or simply cold. Those rules have to come from the business, be written down explicitly, and be re-runnable — because the first version will be wrong for some segment of the data and the second version has to be applied without re-creating everything. That is the step most CRM migration checklists under-weight.

• Preserve original dates in fields you control. Almost every destination platform stamps its own creation date and will not let you override it. If the customer measures anything by record age — lead ageing, time-to-install, cohort performance — that history has to be written into a custom field during the migration. It is a small amount of work at the time and effectively impossible to reconstruct afterwards.