The first question a dealer-principal asks me on a sales call, after they've decided they're leaving DockMaster, is always some variant of: "Will I lose anything?" The fear is specific and justified. Twenty years of records. Every customer they ever sold to. Every service job their techs ever touched. Photos of hulls that sold in 2008 that they might still need for a title correction in 2026.
We've run 42 migrations now. We've moved 12,114 hulls, 38,200 customer records, 94,000 service orders, and roughly 340,000 photos. Zero records lost. Here's the playbook, honestly, including the parts that still don't work.
The eight-step playbook
Step 1. Shadow export, week 0. Before contracts are signed, we run a read-only ODBC pull off the DockMaster SQL backend. Count rows. Profile the data. Find the anomalies. Surface the bad news before the money moves. If something in their data is going to make migration hard, we want the dealer-principal to know before they sign.
Step 2. Field-map workshop, week 1. Two-hour video call with the dealer's most senior admin. We walk through every DockMaster screen and map each visible field to a BoaterOS field. We also find the invisible ones — custom fields, the "dealer notes" blob (more on this below), and the secret knowledge embedded in how they use a field differently from how DockMaster intended.
Step 3. Test migration to sandbox, week 2. Every dealer gets a private BoaterOS sandbox with their real data imported. They can poke at it for a week. Break it. Tell us what's wrong. This is the single highest-leverage step we run. Most issues surface here, where nothing is live.
Step 4. Parallel run, weeks 3-4. DockMaster stays live. BoaterOS runs alongside. A daily delta import pulls new records from DockMaster into BoaterOS. The dealer's team works in DockMaster for 4 days/week, BoaterOS for 1 day/week. Muscle memory transfers gradually.
Step 5. Staff training, week 4. Three sessions, 90 minutes each. Sales flow, service flow, admin flow. We record every session and leave the transcripts in the dealer's BoaterOS workspace. Every dealer has re-watched at least one after go-live.
Step 6. Hard cutover, week 5. Saturday morning. DockMaster goes read-only. Final delta import. Photos reconciled. Website DNS flips to the new Next.js site. By Sunday evening, the new stack is the one that's live.
Step 7. Fire watch, weeks 5-6. A BoaterOS engineer is on-call for two weeks post-cutover with a dedicated Slack channel. Most questions are "how do I do X?" rather than "X is broken," but we treat both with equal urgency. The service-bay techs will find bugs your sales team never would.
Step 8. 90-day review. We come back, look at the lift numbers, see what the dealer isn't using that they should be, and prune any custom fields that turned out to be legacy noise. Half of dealers archive 20+ fields they thought they needed.
"The number-one migration failure mode isn't data. It's that people forget how the old system used to lie to them. We spend more time unlearning DockMaster than importing it."
The edge cases we hit the most
The one field we still can't auto-map
DockMaster has a free-text "Dealer Notes" field on every hull. It's a 4,000-character blob. According to DockMaster's own documentation, it's meant for things like "scratch on port gunwale near cleat." In practice, 38% of the dealers we've migrated use it as an informal tagging system.
We see entries like:
Asterisks. Owner initials. Internal codes. References to other hull IDs. Prioritization language. Event references. All of it meaningful, none of it structured.
We've built an LLM-based parser that auto-classifies these notes into structured tags (owner, priority, linked-hull, event, status) with 82% accuracy. It's the single hardest natural-language task in our product. We do a human-in-the-loop review pass with the dealer's most senior admin during step 2 of the playbook, where they correct the parser's misclassifications. After 42 migrations, we still have not found a way to skip that review step.
We've made peace with this. The admin doing that review is building a shared language with us about their dealership. That's not a migration tax — it's the beginning of a relationship.
Three lessons nobody writes in the SOW
Lesson one: the slowest person on the team sets the go-live date. It's almost always the service-writer who's been doing things the same way for 16 years. We don't accelerate them. We align with them. Their trust is worth more than two weeks of calendar.
Lesson two: the website is 40% of the migration pain, 80% of the buyer-facing outcome. Every DockMaster dealer has a WordPress site that was lovingly customized by a local agency that no longer exists. Rebuilding it — not porting it — is the right call every time. We bring all the inventory, we don't bring the 2014-era testimonials carousel.
Lesson three: name your migration lead on the dealer's side. Without a named internal champion, migrations stall at step 4. The champion doesn't have to be the dealer-principal. It usually shouldn't be. It's usually the sharpest admin, the F&I manager, or a sales manager who's been quietly tired of DockMaster for six years and is ready.
Sophia Reyes is Head of Customer at BoaterOS. She has personally shepherded 27 of the 42 migrations covered in this post and has a framed DockMaster CD-ROM on her desk.