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 this once, end to end, for real: Fish Tale Boats, three Gulf Coast locations, off DockMaster and a stack of marketing tools in six weeks. We moved every hull, every contact, every open deal, with zero records lost. This is the playbook we wrote doing it, including the parts that still don't work. It is the same eight steps we would run for your lot.
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 increase numbers, see what the dealer isn't using that they should be, and prune any custom fields that turned out to be legacy noise. At Fish Tale we archived more than 20 fields the team thought they needed and never opened.
"The number-one migration failure mode isn't data. It's that people forget how the old system used to lie to them. We spent 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, dealers use it as an informal tagging system, and Fish Tale was no exception.
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). It's the single hardest natural-language task in the 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. At Fish Tale we still did not find a way to skip that review step, and we don't expect to skip it on your lot either.
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 ran the Fish Tale migration end to end and has a framed DockMaster CD-ROM on her desk.