Recognising lock-in
Lock-in doesn't show at purchase time, it surfaces when you try to leave. Four objective signs, independent of the sticker price:
- No full export exists, or the export only covers a subset of the data (no attachments, no history, no custom fields).
- Price climbs with actual business usage (per seat, per volume, per module) rather than with perceived value — the tool punishes the growth it was meant to support.
- Features you already used move behind a higher tier during a pricing overhaul, with nothing changed on your side.
- The question "what if you shut down, or changed policy tomorrow" has no reassuring answer — because nothing in the contract commits the vendor on that point.
What makes leaving hard — and what shouldn't
Two things make a migration costly, and only one is legitimate. The legitimate cost: rebuilding a workflow refined over years of real use — statuses, approvals, exceptions learned on the ground. That work has real value and takes time, whatever the destination tool.
The illegitimate cost: a proprietary data format, a deliberately crippled export, a support team that slows down a cancellation request. That isn't a technical cost — it's commercial friction dressed up as a technical limitation. Telling the two apart keeps you from giving up on leaving for a reason that isn't really one.
The method to leave without a big bang
Migration starts with structure, never with raw data. Step 1: describe your business AS IT ACTUALLY WORKS TODAY, not as the old tool trained you to enter it — the two often diverge, because a rigid tool gets its own limits worked around with catch-all text fields and repurposed statuses. This is the moment to describe the trade, not the old software's screen.
Step 2: generate the application (the Sketch level, free on the Discovery plan, is enough for this check) and test it against three or four real cases from your week — a complicated file, an exception, an edge case the old tool handled awkwardly. This is where the old system's unspoken rules surface.
Step 3: adjust the description and regenerate until the structure holds. Only then, step 4: switch the CURRENT flow over to the new application; keep the old tool accessible read-only during the transition, without re-entering anything new into it.
What isn't automatic: historical data
Let's be direct: Blueprint Maker doesn't wire up automatic import from a third-party tool — no generation tool can honestly promise that across every proprietary format on the market. What's actually possible: export whatever the old tool agrees to release (usually a partial CSV), use it as a reference to check the generated structure matches reality, and re-enter, or have someone re-enter, whatever data still matters. Since the code is standard, exportable Next.js and Prisma, a developer can also wire a one-off import script from that export — a bounded piece of work, not a permanent dependency.
The good news: most migrations don't need the full history. Active records and the last few months are almost always enough; the archive stays available read-only in the old tool for as long as it's needed.
The traps of leaving lock-in
First trap: reproducing the old software's screens exactly. Its fields and menus usually reflect the limits of ITS technology, not your trade's needs — copying them imports the next lock-in along with the old one.
Second trap: aiming for 100% of the history before switching over. That's the surest way to never leave. Current flow first, archive later if it's genuinely needed.
Third trap: trading one lock-in for another. This is what code ownership solves structurally: a generated application exports (ZIP, GitHub push) and hosts wherever you choose — leaving Blueprint Maker someday follows exactly the same logic as leaving the old tool today, only far simpler.