Forem: Andrew Lee Jenkins

Exporting CRM data is messier than you think: migration scripts for Honeybook, Dubsado, and 17hats

Andrew Lee Jenkins — Sat, 16 May 2026 15:00:36 +0000

I've scripted CRM migrations from Honeybook, Dubsado, and 17hats. The CSV exports are dirtier than you'd expect. Here are the scripts I use.

Related reading on owning your CRM stack - https://seedlycrm.com/blog/gohighlevel-alternatives-where-you-own-the-code

Why this post exists

I run an agency for home service businesses. A lot of my onboarding work isn't the fun stuff. It's getting a client's data out of whatever boutique CRM they're stuck in and into a schema that doesn't make me want to punch a wall.

Each of these three platforms exports differently, and each one has its own brand of "yeah we technically gave you your data" energy.

Export reality: Honeybook

Honeybook's export is a zip with multiple CSVs. Contacts, projects, payments, files. Quoting is inconsistent across older exports, so a naive pd.read_csv will eat it alive.

Things to know going in:

Phone numbers come through as strings with formatting characters baked in.
Project status uses internal codes that aren't documented in the export.
Notes can contain raw HTML from rich-text inputs.
Date fields are ISO-ish, but they don't tell you the timezone is UTC.

import pandas as pd

contacts = pd.read_csv(
    "honeybook_export/contacts.csv",
    engine="python",         # the C engine chokes on inconsistent quoting
    dtype=str,               # never trust pandas type inference on dirty CSVs
    keep_default_na=False,
    encoding="utf-8-sig",    # strip the BOM honeybook adds
)

Export reality: Dubsado

Dubsado makes you export each section separately. Clients, projects, leads, invoices. There's no "give me everything" button. You'll be clicking for ten minutes.

The clients CSV has a tags column that's a single string of comma-separated tags. So now you have commas inside a comma-delimited file. The export wraps that field in quotes most of the time, but I've seen cases where it doesn't.

The bigger problem is custom fields. Dubsado lets clients add custom fields per-project, and those come through as columns named whatever the user typed. I once opened an export with 60+ columns because someone got creative with their intake form.

def load_dubsado_clients(path):
    df = pd.read_csv(path, dtype=str, keep_default_na=False)

    core = {"name", "email", "phone", "company", "address", "tags", "status"}
    custom_cols = [c for c in df.columns if c.lower() not in core]

    # collapse unknown columns into a single notes blob
    df["_custom_blob"] = df[custom_cols].apply(
        lambda row: "\n".join(
            f"{k}: {v}" for k, v in row.items() if v.strip()
        ),
        axis=1,
    )
    return df.drop(columns=custom_cols)

If the client wants those custom fields preserved, you map them to your target CRM's custom field schema. If they don't care (most don't), it goes in notes.

Export reality: 17hats

17hats gives you contacts and projects as separate CSVs. The contact identifier isn't called contact_id. It's called Contact #. With a space and a hash symbol. Welcome to migration.

The phone column can contain multiple numbers in one cell, separated by a slash or an "alt:" prefix. So (804) 555-1234 / alt: 804-555-9999 is a real value I've parsed.

import re

PHONE_RE = re.compile(r"[\d\(\)\-\s\+]+")

def split_17hats_phones(raw):
    if not raw:
        return []
    parts = re.split(r"[/;]|alt:", raw, flags=re.IGNORECASE)
    cleaned = []
    for p in parts:
        match = PHONE_RE.search(p)
        if match:
            digits = re.sub(r"\D", "", match.group())
            if len(digits) >= 10:
                cleaned.append(digits[-10:])
    return cleaned

You'll thank me when your SMS sender isn't trying to text "alt:" as a destination.

The CSV pitfalls that bite everyone

I keep a checklist I run before I touch anything:

BOM at the start of the file. UTF-8 with BOM is common in older exports. Use encoding="utf-8-sig".
Mixed line endings. Windows \r\n and Unix \n in the same file. pandas usually handles it. csv.reader sometimes doesn't.
Embedded newlines in fields. Notes with line breaks will split into multiple "rows" if you read line-by-line. Always use a real CSV parser.
Smart quotes. Curly quotes from someone who pasted in from Word will not match your search filters. Normalize to straight quotes.
Trailing whitespace in emails. john@example.com is not john@example.com to most CRMs. Strip.
Duplicate contacts. Same person entered twice with different formatting. Match on lowercase trimmed email first, then on (name, phone) as a fallback.
Empty strings vs nulls. Some CSVs use "", some use NULL, some use N/A. Normalize on load.

def normalize_email(s):
    if not s:
        return None
    s = s.strip().lower()
    return s if "@" in s else None

def normalize_phone(s):
    if not s:
        return None
    digits = re.sub(r"\D", "", str(s))
    if len(digits) == 11 and digits.startswith("1"):
        digits = digits[1:]
    return digits if len(digits) == 10 else None

The reusable script template

Every migration I write follows the same shape. Load, normalize, map fields, validate, write. I keep it boring on purpose.

# migrate.py
import pandas as pd
import json
import sys
from pathlib import Path

def load(source, path):
    loaders = {
        "honeybook": load_honeybook,
        "dubsado":   load_dubsado,
        "17hats":    load_17hats,
    }
    return loaders[source](path)

def normalize(df):
    df["email"] = df["email"].apply(normalize_email)
    df["phone"] = df["phone"].apply(normalize_phone)
    df["name"]  = df["name"].str.strip()
    return df

FIELD_MAP = {
    # source_column : target_column
    "email":        "primary_email",
    "phone":        "primary_phone",
    "name":         "full_name",
    "company":      "company_name",
    "tags":         "tag_list",
    "_custom_blob": "notes",
}

def map_fields(df, mapping=FIELD_MAP):
    out = pd.DataFrame()
    for src, dst in mapping.items():
        out[dst] = df[src] if src in df.columns else None
    return out

def validate(df):
    errors = []

    no_contact = df[df["primary_email"].isna() & df["primary_phone"].isna()]
    if len(no_contact):
        errors.append(f"{len(no_contact)} rows have no email or phone")

    dupes = df[df["primary_email"].duplicated(keep=False) & df["primary_email"].notna()]
    if len(dupes):
        errors.append(f"{len(dupes)} duplicate emails")

    return errors

def write(df, out_path):
    df.to_csv(out_path, index=False, encoding="utf-8")

if __name__ == "__main__":
    source, in_path, out_path = sys.argv[1], sys.argv[2], sys.argv[3]
    df = load(source, in_path)
    df = normalize(df)
    df = map_fields(df)
    errs = validate(df)
    if errs:
        print("VALIDATION FAILED:")
        for e in errs:
            print(" -", e)
        sys.exit(1)
    write(df, out_path)
    print(f"wrote {len(df)} rows to {out_path}")

Usage:

python migrate.py honeybook ./exports/contacts.csv ./out/contacts.csv

Validate before you import. Always.

The thing that has saved me from "hey Andrew our CRM thinks every customer has the same email" is dry-running the import against a staging instance and diffing the counts.

My validation pass checks:

row count matches the source (no silent drops)
every row has at least one contact method
no duplicate primary emails
phone numbers are exactly 10 digits after normalization
timestamps parse cleanly
tag list has no empty strings

If any of those fail, the script exits non-zero and I don't touch the prod CRM. If I'm feeling fancy I pipe the validation report to a JSON file the client can review before I press the button.

def write_report(df, errs, path):
    Path(path).write_text(json.dumps({
        "total_rows": len(df),
        "rows_with_email": int(df["primary_email"].notna().sum()),
        "rows_with_phone": int(df["primary_phone"].notna().sum()),
        "errors": errs,
    }, indent=2))

Client sees the report. Client signs off. Then I import. Has saved my ass more than once when someone went "wait, we don't have 4,000 contacts, we have 400" and we caught it before it hit production.

What I'd do differently starting today

Skip the CSV middle step entirely if the source has a real API. Honeybook does, kind of. Dubsado does not in any meaningful sense. 17hats is a no.

If you're stuck with CSVs, version-control them. Drop the raw export into a git-ignored folder, commit the normalized output, and you'll have an audit trail when the client emails you in six months asking why a contact looks different.

Also: write the script for your worst client, not your best one. The one with 14 years of half-finished projects and free-text status fields where someone typed "idk?" 47 times. If your script handles them, it handles anyone.

If you've done one of these migrations and hit something I didn't cover, drop it in the comments. I'm building my own CRM right now specifically so I never have to do another Dubsado export, and I'd love to know what I'm missing on the import side.

I've white-labeled the same CRM codebase 7 times for 7 different clients. I never touch the core. Here's how the override layer works.

Andrew Lee Jenkins — Wed, 13 May 2026 17:20:36 +0000

This is the pattern I wish someone had handed me two years ago when I was still git-branching every client into their own forked repo (yes, really, it was as bad as it sounds). One client needs different colors. Another needs their logo on the login screen. A third wants to hide the entire invoicing module because they only use it for lead capture. If you fork the core for each of those, you're signing up to merge bug fixes across 7 repos forever.

Don't do that. Here's what I do instead.

The mental model: core stays sacred, everything else is config

The trick is treating your CRM as two things stacked on top of each other:

Core app code. Routes, business logic, database schema. Untouchable. Same for every tenant.
A branding + feature override layer. Env vars, CSS tokens, email templates, assets, feature flags. This is the ONLY thing that changes between deployments.

When I onboard a new white-label client, I clone the same repo, drop in a new .env, swap a few files in /public/brand/, flip a couple flags, and ship. No git diff against the core. Ever.

Let me walk you through each layer.

Step 1: environment-based branding

This is where most people start, and most people stop. The env file is doing way more work than just storing API keys.

# .env.production (client A: Apex Plumbing)
NEXT_PUBLIC_APP_NAME="Apex CRM"
NEXT_PUBLIC_APP_DOMAIN="crm.apexplumbing.com"
NEXT_PUBLIC_SUPPORT_EMAIL="help@apexplumbing.com"
NEXT_PUBLIC_BRAND_PRIMARY="#0F4C81"
NEXT_PUBLIC_BRAND_ACCENT="#F4A300"
NEXT_PUBLIC_LOGO_PATH="/brand/apex/logo.svg"
NEXT_PUBLIC_FAVICON_PATH="/brand/apex/favicon.ico"
NEXT_PUBLIC_LOGIN_BG="/brand/apex/login-bg.jpg"

Same repo, different .env:

# .env.production (client B: Riverside Roofing)
NEXT_PUBLIC_APP_NAME="Riverside HQ"
NEXT_PUBLIC_APP_DOMAIN="hq.riversideroofing.com"
NEXT_PUBLIC_SUPPORT_EMAIL="ops@riversideroofing.com"
NEXT_PUBLIC_BRAND_PRIMARY="#1A3A2A"
NEXT_PUBLIC_BRAND_ACCENT="#C7522A"
NEXT_PUBLIC_LOGO_PATH="/brand/riverside/logo.svg"
NEXT_PUBLIC_FAVICON_PATH="/brand/riverside/favicon.ico"
NEXT_PUBLIC_LOGIN_BG="/brand/riverside/login-bg.jpg"

Then I read those once in a single brand.config.ts so the rest of the app doesn't have to care:

// lib/brand.config.ts
export const brand = {
  appName: process.env.NEXT_PUBLIC_APP_NAME ?? "CRM",
  domain: process.env.NEXT_PUBLIC_APP_DOMAIN ?? "localhost:3000",
  supportEmail: process.env.NEXT_PUBLIC_SUPPORT_EMAIL ?? "",
  colors: {
    primary: process.env.NEXT_PUBLIC_BRAND_PRIMARY ?? "#111111",
    accent: process.env.NEXT_PUBLIC_BRAND_ACCENT ?? "#FF6600",
  },
  assets: {
    logo: process.env.NEXT_PUBLIC_LOGO_PATH ?? "/brand/default/logo.svg",
    favicon: process.env.NEXT_PUBLIC_FAVICON_PATH ?? "/brand/default/favicon.ico",
    loginBg: process.env.NEXT_PUBLIC_LOGIN_BG ?? "/brand/default/login-bg.jpg",
  },
};

Now anywhere in the app, brand.appName and brand.colors.primary just work. No hardcoded strings, no per-client if (tenant === "apex") branches. The core doesn't know who it's deployed for and that's the WHOLE point.

Step 2: theme overrides via CSS variables

Tailwind is fine, but the second you start dynamic theming with pure Tailwind classes you end up with bg-blue-600 hardcoded in 200 components. Don't do that. Bind your brand colors to CSS custom properties at the root, then point Tailwind at those.

/* app/globals.css */
:root {
  --color-brand-primary: 15 76 129;   /* RGB triplet, set at runtime */
  --color-brand-accent: 244 163 0;
  --color-bg: 255 255 255;
  --color-fg: 17 17 17;
}

[data-theme="dark"] {
  --color-bg: 12 12 14;
  --color-fg: 240 240 240;
}

// tailwind.config.ts
export default {
  theme: {
    extend: {
      colors: {
        brand: {
          primary: "rgb(var(--color-brand-primary) / <alpha-value>)",
          accent: "rgb(var(--color-brand-accent) / <alpha-value>)",
        },
        bg: "rgb(var(--color-bg) / <alpha-value>)",
        fg: "rgb(var(--color-fg) / <alpha-value>)",
      },
    },
  },
};

Then in your root layout, you inject the brand colors from the env at runtime so the same JS bundle works for every tenant:

// app/layout.tsx
import { brand } from "@/lib/brand.config";

function hexToRgb(hex: string) {
  const h = hex.replace("#", "");
  const r = parseInt(h.slice(0, 2), 16);
  const g = parseInt(h.slice(2, 4), 16);
  const b = parseInt(h.slice(4, 6), 16);
  return `${r} ${g} ${b}`;
}

export default function RootLayout({ children }) {
  const style = {
    "--color-brand-primary": hexToRgb(brand.colors.primary),
    "--color-brand-accent": hexToRgb(brand.colors.accent),
  } as React.CSSProperties;

  return (
    <html lang="en" style={style}>
      <head>
        <title>{brand.appName}</title>
        <link rel="icon" href={brand.assets.favicon} />
      </head>
      <body>{children}</body>
    </html>
  );
}

bg-brand-primary and text-brand-accent now resolve to whatever the env says. Zero code changes between tenants.

Step 3: email template overrides

This is where I see people fall over. They hardcode "Welcome to MyApp!" into the transactional emails and then have to fork the templates for every client. Same idea as above: read from brand, never hardcode.

// emails/welcome.tsx (using react-email)
import { brand } from "@/lib/brand.config";

export function WelcomeEmail({ firstName }: { firstName: string }) {
  return (
    <Html>
      <Body style={{ backgroundColor: "#f6f6f6" }}>
        <Container>
          <Img src={`https://${brand.domain}${brand.assets.logo}`} width="140" />
          <Heading>Welcome to {brand.appName}, {firstName}.</Heading>
          <Text>
            If you get stuck, hit reply or email {brand.supportEmail}.
          </Text>
          <Text style={{ color: "#888", fontSize: 12 }}>
            Sent by {brand.appName} | {brand.domain}
          </Text>
        </Container>
      </Body>
    </Html>
  );
}

For clients who want truly different copy (not just different branding), I add a thin override directory the build resolves before the default:

/emails
  /default/
    welcome.tsx
    invoice-sent.tsx
  /overrides/
    apex/
      welcome.tsx        <- only the files Apex wants different
    riverside/
      invoice-sent.tsx

Then a tiny resolver picks the override if it exists:

// lib/email/resolve.ts
import { brand } from "@/lib/brand.config";

const tenant = process.env.BRAND_KEY ?? "default";

export async function loadEmail(name: string) {
  try {
    return (await import(`@/emails/overrides/${tenant}/${name}`)).default;
  } catch {
    return (await import(`@/emails/default/${name}`)).default;
  }
}

Default lives in the core. Overrides live in a per-tenant folder. The core never gets touched.

Step 4: asset replacement

Logos, favicons, login backgrounds, OG share images. I keep them all under /public/brand/<key>/ and let the env path point at the right one.

/public
  /brand
    /default/
      logo.svg
      favicon.ico
      login-bg.jpg
      og-image.png
    /apex/
      logo.svg
      favicon.ico
      login-bg.jpg
      og-image.png
    /riverside/
      logo.svg
      ...

Components just reference brand.assets.logo. The build copies the right folder. Done.

One thing that bit me early on: don't forget the OG/Twitter card image. I shipped a client and his Slack previews still showed the default logo for 3 days because I forgot to update app/opengraph-image.tsx. Get it right the first time so you're not chasing it later.

// app/opengraph-image.tsx
import { ImageResponse } from "next/og";
import { brand } from "@/lib/brand.config";

export default async function OG() {
  return new ImageResponse(
    (
      <div style={{ background: brand.colors.primary, display: "flex" }}>
        <h1 style={{ color: "white" }}>{brand.appName}</h1>
      </div>
    ),
    { width: 1200, height: 630 }
  );
}

Step 5: feature flags per tenant

This is the unlock. Some clients want the invoicing module. Some don't. Some want SMS sequences enabled. Some don't have an A2P approval yet so SMS would just error. Feature flags let you toggle entire modules without if (tenant === "x") mess.

// lib/features.ts
export type FeatureKey =
  | "invoicing"
  | "sms_sequences"
  | "pipeline_automations"
  | "client_portal"
  | "ai_replies";

const flagEnv = process.env.NEXT_PUBLIC_FEATURE_FLAGS ?? "";
const enabled = new Set(
  flagEnv.split(",").map((s) => s.trim()).filter(Boolean)
);

export function feature(key: FeatureKey): boolean {
  return enabled.has(key);
}

# Apex .env
NEXT_PUBLIC_FEATURE_FLAGS="invoicing,client_portal,pipeline_automations"

# Riverside .env (no SMS yet, no invoicing)
NEXT_PUBLIC_FEATURE_FLAGS="client_portal,ai_replies"

Then in your nav, your routes, your settings UI...

{feature("invoicing") && (
  <NavItem href="/invoices" icon={Receipt}>Invoices</NavItem>
)}

{feature("sms_sequences") && <SmsSequenceBuilder />}

You can take this further with per-tenant config in your DB if you want flags to be toggleable at runtime. For SMB white-label work, env-level flags are usually enough and they're WAY easier to reason about.

Why I refuse to fork the core

I learned this from a client situation that could've gone really sideways. The setup: one client, two brands. The main brand was established and ranking. The sister brand had ZERO online presence, tumbleweeds-blowing-through-the-desert kind of nothing. We needed to spin up a second tenant fast, borrow from the existing brand's authority to bootstrap the new one, and not babysit two codebases while doing it.

Because the CRM was wired up like the steps above, deploying tenant #2 was literally:

Clone the repo
New .env
New /public/brand/sister/ folder
New deploy on a subdomain
Done

Maybe an hour, most of which was waiting for DNS. If I'd forked, I'd have been merging hotfixes across two repos for the rest of the year while trying to actually run a marketing campaign for the second brand. No thanks.

Forking feels productive in the moment because you can hack on the new client's code without breaking anyone else. But you've just signed yourself up to maintain N repos forever. The override layer takes one weekend to build and saves you that work for the entire lifespan of the product.

The one rule

If you find yourself reaching for git checkout -b client-acme to add a brand-specific feature... stop. Go back to the override layer and ask "is this a config thing, an asset thing, an email thing, or a feature flag thing?" 95% of the time, the answer is one of those four and your core never needs to know the client exists.

The other 5% is where you have an honest conversation with the client about whether the customization is worth the complexity, or whether they should just use the product as it stands. (Spoiler: it almost always is the latter, they just haven't been told no yet.)

My CRM source code ships with this override layer built in: env-driven branding, CSS-variable theming, email overrides, asset folders, and the feature flag system above, all already wired up. Link in profile if you want to see how it's structured.

Howdy!

Andrew Lee Jenkins — Tue, 12 May 2026 22:33:46 +0000

Hey, I'm Andrew. Engineer turned marketer turned engineer-again. Glen Allen, VA.

The short version: I spent over a decade in engineering and design consulting for Fortune 500 companies. Left to start a marketing agency for home service businesses (contractors, cleaners, HVAC, the trades). Spent years watching my clients get fleeced by SaaS vendors that triple their prices on renewal. Eventually got annoyed enough to start building the software myself.

What I'm building

Seedly CRM is a self-hosted, source-available CRM I sell as source code. One payment of $1,050, you own it forever. No per-seat fees, no monthly bill, no vendor holding your customer data hostage. Built for service businesses and the agencies that serve them.

Other things I ship (mostly WordPress-adjacent right now): a UTM lead-tracking dashboard, a bulk image processor, and a local-maps plugin called Maps Uncensored.

What I write about

Mostly building in public. Decisions behind Seedly, why I went source-available instead of SaaS, what breaks when you sell software to non-developers, the weird overlap between marketing infrastructure and developer tools.
Where else to find me

🌐 andrewleejenkins.com
🌱 seedlycrm.com
🎙️ Growth Unfiltered (podcast)
💼 LinkedIn
📺 YouTube