Three moves, in this order. Get your data out while the service still runs: contractual restitution usually covers it, and the right to data portability backs you up. Then secure operations for the length of the switch, because software that still runs is not the same as software that is safe. Finally, pick a replacement by asking the question you missed the first time: if this vendor stops too, what stays in my hands?
What actually happens when a vendor stops
Rarely a clean cut-off. Most of the time the software keeps working: that is what makes the situation comfortable and dangerous. Fixes stop, compatibility with browsers and systems drifts, a regulatory change goes unfollowed, and the day something breaks there is nobody left to fix it.
This is not a rare predicament: the providers who take over these cases describe steady, and usually urgent, demand — companies call when the outage is here, not when the announcement lands. The best moment to act is therefore precisely the one where nothing seems pressing.
Getting your data out: what you are entitled to
Your data belongs to you. Its return at the end of the contract is generally provided for by the contract itself, and European data protection rules separately grant a right to portability in a structured, machine-readable format. Ask for that export in writing, without waiting for the deadline.
An export is only useful if it can be used. Ask for an open format (CSV, JSON, SQL) rather than a proprietary backup nobody will be able to read, and ask for the field descriptions: a 40-column file with no dictionary costs more to decode than to retype.
- Export NOW, while the service and a contact person still exist.
- Require an open format and field descriptions, not just a dump.
- Check the export by actually opening it: expected rows, accents, dates, attachments.
- Keep a copy outside the service, on your own storage, before any termination.
- Write down what you could NOT retrieve: that is what will shape the next step.
Picking a replacement without recreating the dependency
The question to ask a new vendor is not “will you last?” — everyone answers yes, and nobody can promise it. The right question is: if you stop, what stays in my hands, and in what form? A service that can only answer with a data export will leave you, when the day comes, exactly where you are now.
That is the principle behind Blueprint Maker: you describe your need, the application is generated and deployed, and the source code is handed to you from the start. ZIP export, push to your own GitHub repository, host it yourself or use the dedicated URL provided: a standard Next.js and Prisma project, the structure every web developer knows. Blueprint Maker is a company like any other, and that is exactly why not depending on it to run your tool matters.
Three generation levels (Sketch, Craft, Masterpiece) and a free Discovery plan let you test the takeover on a reduced scope before committing to the full migration: generating a first version from your exported data costs less than a scoping meeting.
A realistic timeline
Do not switch under emergency if you can avoid it. The order that works: retrieve the data, rebuild the real requirement calmly — what the old tool actually did, not what it promised —, generate and test the replacement in parallel, then switch with the old system still readable long enough to verify.
That rebuilding is the one benefit of the situation: an inherited tool always holds screens nobody uses and constraints nobody can explain any more. Replacing it is the chance to carry over only what serves.