Almost every small business starts with Google Forms, and a great many stay long after it stopped being the right tool. Not because it is good enough. Because moving means rebuilding, and rebuilding means somebody sitting down with two browser tabs open and retyping forty questions without making a mistake.
That is a genuinely unappealing afternoon, and it is why people put up with forms that look nothing like their brand, cannot take a payment, cannot branch properly, and send a notification email that looks like it came from a spreadsheet.
The retyping is the whole barrier. Remove it and the decision becomes about whether the new tool is better, which is a much easier question to answer and a much more honest one to ask.
What actually transfers
A form is more than its questions, and it helps to be clear about which parts move cleanly, which move approximately, and which do not move at all.
Questions, their types, their option lists, their ordering and whether they are required all transfer reliably, because every form tool represents those in more or less the same way. That is the bulk of the work and the part nobody wants to do by hand.
Conditional logic transfers less well, because tools model branching differently and there is no shared vocabulary for it. Styling does not transfer at all and should not, since matching your new brand is usually one of the reasons you are moving. Integrations, notifications and anything connected to a spreadsheet have to be set up again, and that is a good thing rather than a loss.
The question types that need attention
Most map one to one. A short answer is a short answer everywhere. A multiple choice is a multiple choice. The ones worth checking after any import are the ones where tools disagree about what the type means.
- Linear scales. Tools differ on whether the range is one to five or zero to ten, and on whether the end labels come across.
- Grids and matrices. Some tools have no equivalent and will flatten a grid into several separate questions, which is usually correct but changes how the data reads.
- File uploads. Size limits and accepted types rarely transfer, and the defaults on either side may not match what you need.
- Date and time. Check whether it kept the distinction between a date, a time and both.
- Anything with other as an option, which some tools treat as a normal choice and others as a choice plus a text box.
Import first, edit second
The mistake is to treat the import as a migration that must be perfect before you touch anything. It is a first draft, in exactly the way a generated form is a first draft, and the right posture is to accept it quickly and then improve it.
Bring the form across, then read it top to bottom as a customer would. You will find things you had stopped noticing on the old version: the question nobody has answered usefully in two years, the option list that is missing the service you launched in spring, the wording that made sense when you wrote it and does not now.
Most people end up changing a third of the form during the move, and almost none of those changes were on the list when they started. That is the real value of migrating, and it only happens because the retyping is not in the way.
Nobody audits a form they are not touching. A migration is the only time most forms get read properly.
Do not import the questions you stopped using
Before you move anything, open the responses to the old form and look at which questions people actually answer and which answers you actually use.
There is nearly always at least one field that is technically collected and functionally ignored: a how did you hear about us where ninety per cent say other, a company name on a form that only consumers fill in, a free text box whose answers nobody has read since the second month. Those do not need to come across, and the migration is the cheapest moment in the form's life to drop them.
It is much harder to remove a question from a live form later, because by then somebody will have built a report on it. Do the cutting during the move.
Multi-step forms are where tools differ most
A single-page form is easy to move because there is only one thing to represent. A multi-step form encodes decisions about where the breaks go and what happens between them, and those decisions are expressed differently everywhere.
Expect page breaks to survive and expect branching between pages to need review. If your old form sent people down different paths, open each path on the new version and walk it, rather than assuming the structure came across intact. This is fifteen minutes and it is the single highest-value check in any migration.
It is also an opportunity. Steps that made sense when the form was shorter often do not once you have cut two questions, and a five-step form frequently wants to be three.
What to do with the old responses
Historical submissions almost never migrate, and mostly that is fine. They are a record rather than a working dataset, and the right move is usually to export them once, keep the file somewhere sensible, and leave them where they are.
If you genuinely need continuity, the practical approach is to keep the old spreadsheet as the archive and start the new form clean, with a note of the changeover date. Trying to merge two differently-shaped datasets is a project, and it is rarely one that earns its keep for a small business.
Do not delete the old form on day one either. Leave it accessible and unpublished for a month in case something was linked from a place you forgot about.
Redirect everything that points at the old one
The most common failure of a form migration is not the form. It is the six places the old link still lives, quietly collecting submissions into a spreadsheet nobody is watching any more.
Make a list before you switch: your website, your email signature, the automatic reply, any printed material with a QR code, your social profiles, the confirmation email from your booking system, and any partner or directory listing. Most businesses find at least two they had forgotten.
Where you can, point the old form at the new one rather than deleting it. Google Forms lets you close a form and show a message, and a message with a link loses far fewer people than a page that simply refuses.
Test with a real submission before you announce it
Import, review and publish is not the end. The part that goes wrong is everything downstream of the form, and none of it is visible from the builder.
Submit the form yourself, as a customer, on a phone. Check the notification arrives, at the right address, with the answers in a readable shape. Check the confirmation the customer sees says the right thing. Check any integration fired. If you take payments, run one real transaction for a small amount and then refund it.
Ten minutes of this catches the problems that would otherwise be discovered by a customer, and being told by a customer that your form is broken costs more than the form was ever worth.
What gets better, concretely
It is worth being specific about why anybody bothers, because move to a better tool is not an argument.
The form stops looking like it belongs to somebody else, which matters more for enquiry forms than people admit. Branching gets easier to build and much easier to change. Notifications become readable. You can take a deposit at the moment of interest rather than chasing one afterwards. And you get analytics that tell you where people leave, which is the difference between guessing and knowing.
None of those individually forces a migration. Together they are usually worth an afternoon, and the point of importing is that it is no longer an afternoon.
When the import will not work
Be realistic about the cases that need manual work. A form behind a login cannot be read by anything, so a private internal form has to be recreated or made temporarily public. A form built as a custom page on somebody's website is not a form in any structured sense and will not import.
Very unusual question types, particularly anything involving calculations, scoring or an embedded widget, will come across as their nearest plain equivalent. That is usually the right answer and it is worth knowing in advance rather than discovering it in review.
For anything that does not import, the questions are still the easy part. Copy the text across and rebuild the behaviour, which is the part you were going to want to change anyway.
Telling people the form has moved
If the form is one your regulars use, a silent swap causes more confusion than it saves. People have the old link bookmarked, and some of them will assume the new one is a phishing attempt, particularly if the domain changed.
A single line in your next email is enough. Our booking form has a new home, here it is, the old one will stop working at the end of the month. It costs nothing and it removes an entire category of support question, along with the small number of people who would otherwise quietly stop using it.
For anything printed, be honest about the timeline. A QR code on a leaflet cannot be updated, so the old form needs to keep redirecting for as long as those leaflets are in circulation, which is usually longer than anyone plans for.
Why the import has to be exact
There is a temptation, when building this kind of tooling, to have a model read the old form and produce something similar. That works impressively in a demo and fails in the way that matters, which is quietly.
A model asked to reproduce a form will occasionally improve it. It will rename a question, merge two options, drop one that seemed redundant, or standardise a scale. Every one of those is a plausible edit and every one of them means the imported form is not the form you had, and you will not notice until a submission arrives missing something.
Deterministic extraction is less glamorous and it is the right approach for anything called an import. Read the structure, map it across, and say plainly what could not be carried over. A list of three things that need attention is far more useful than a form that looks complete and has silently changed.
A sensible order of operations
If you are doing this for the first time, this sequence keeps it to under an hour and stops anything falling over in public.
- Read the old responses and decide which questions do not deserve to move.
- Import by URL and let the structure come across.
- Read the result as a customer, top to bottom, and fix wording as you go.
- Walk every branch of a multi-step form individually.
- Set up notifications and anything downstream, then send a real test submission from a phone.
- Swap the links everywhere, using a list you wrote before you started.
- Close the old form with a message and a link rather than deleting it.
- Leave it a fortnight before you archive anything.