How to switch client portals without losing clients

How to switch client portals without losing clients comes down to four moves: export everything from the old portal first, move only what open work needs, run both portals for one billing cycle, and pick a new portal that does not make clients create an account. The export and the overlap are the firm’s work. The account step is the client’s work, and it is the step that decides whether the switch holds. A client who has to accept an invitation, invent a password and confirm an email before they can upload one file will email the file instead, and the firm ends up with a new portal and the old inbox.

Picking the new portal is the short part of a client portal migration. The hard part comes after it: the week the firm tells four hundred clients that the place they used to send things has moved, and finds out how many of them follow.

Why do client portal switches fail?

Because the cost of the switch lands on the client, and the client did not choose it.

The firm decides to change portals for good reasons. The old one charges per seat and the team grew. It has no e-signature, so letters go out through a second tool. Clients complain they cannot find the upload button on a phone. Staff spend Monday mornings resetting passwords. None of those reasons mean anything to the client. From their side, a portal they finally learned is being taken away, and they are being asked to learn another one.

Then the invitation arrives. It comes from a sender name they have never seen, with a subject line like “You have been invited to join” and a button that leads to a sign-up form. Some clients read it as phishing and delete it. Some click, see a password field with rules about symbols and length, and close the tab. Some create the account, forget the password by March, and hit the reset flow on the day a document is due. Each of those clients defaults to the channel they trust, which is replying to the firm’s last email with an attachment.

That is the re-registration cliff. It is not a data problem, and no export tool fixes it. A firm can move every file and every client record perfectly and still end the quarter with half its clients sending documents by email, because the new portal asked each of them to do a job they never agreed to.

The other failures are smaller and easier to see coming:

• Open requests get stranded. A client was halfway through uploading tax documents in the old portal when the firm switched, and nobody knows which items are still missing.
• Staff keep using the old portal because the history is there, and the new one fills up with half the picture.
• The old contract auto-renews because nobody checked the notice date, and the firm pays for two portals for a year.
• Old files get dumped into the new portal in one unsorted folder per client, so nobody can find anything, and the clutter makes the new portal look worse than the old one.

Every one of those can be planned for. The account step can only be avoided, by choosing a portal that does not have one for clients.

What should you decide before you export anything?

Four things, written down, before anyone touches a download button.

The first is the cutover date: the day new requests stop going out from the old portal. Pick a date outside the firm’s busy season. For a tax firm that rules out mid-January through April 15. For a law firm it means a stretch with no large matter closing. The old portal stays open after cutover. Only new work stops going there.

The second is the shutdown date. Read the old contract for the renewal date and the notice period. A portal on an annual term with a 30-day notice clause has to be cancelled a month before renewal, and missing that means a second year of fees. Set the shutdown at least one full billing cycle after the cutover, and set the cancellation reminder now.

The third is who owns the switch. One named person, with a list, and the authority to tell partners that the old portal is closed to new requests. A switch with no owner drifts. Staff who are busy will keep using whatever is open.

The fourth is what the new portal has to do on day one. Write the three or four workflows the firm runs most, such as new client intake, the annual document request and the engagement letter, and check that each one works end to end in the new portal before cutover. A firm that discovers in week two that the new portal cannot send an e-signature request has to keep the old tool, and then it has two portals with no end date.

How to export from the old client portal

Export more than you plan to move. The export is the firm’s copy of record, and once the old account closes, anything not exported may be gone. Read the old contract for how long the vendor keeps data after cancellation, and plan as if the answer is zero days.

Pull these, in this order:

1. The client list, with every field the old portal holds: name, email, phone, company, any custom fields, and the date each client last logged in. Last-login date is the most useful column in the whole migration, because it shows who actually uses the portal and who never did.
2. Every uploaded file, in a folder per client, named the way the firm names clients everywhere else. If the old portal exports files with internal IDs instead of names, fix the mapping before anything else, because it gets harder to do later.
3. Every signed document, with its audit record or certificate. A signed engagement letter without the record of who signed it and when is weaker evidence than the same letter with one. Export the signature certificates as files, not as screenshots.
4. Open requests: for each client with live work, what was asked, what came back and what is still missing. If the old portal has no report for this, a spreadsheet built by hand from the request screens is fine. This list drives the first week after cutover.
5. Message history, if the portal holds client messages that the firm may need later. Export it as PDF per client and file it with the client’s documents.

Check the export before you trust it. Open ten client folders at random and compare them against the old portal. Count the files. Open a signed document and confirm the certificate is there. A failed export found in week one is an annoyance. Found in month six, it is a missing record.

Store the export outside both portals: the firm’s document management system, its file server, or an encrypted archive the firm controls. That copy is the archive, and only a small part of it should ever reach the new portal.

What should you not move to the new client portal?

Most of it. Anyone working out how to migrate a client portal should treat the new one as the place for work in progress and for what clients need to see. The firm’s records live somewhere else.

Move these:

• Active clients, meaning anyone with open work or a request due in the next year.
• Open requests and the files already received against them, so the client does not get asked twice for something they sent.
• The current year’s signed engagement letter or retainer, if clients reach it through the portal.
• Anything the firm’s workflow references every year, such as last year’s return for a returning tax client.

Leave these in the archive:

• Clients who have not logged in or sent anything in two years. Invite them when they come back.
• Closed matters and finished returns. Keep them where the firm keeps records, not in a portal clients can browse.
• Duplicate uploads, blurry first attempts and wrong files a client replaced.
• Old message threads about work that is done.

Some of what the firm leaves behind it may also have to dispose of. The FTC Safeguards Rule covers tax preparation firms among other financial businesses, and it tells them to “securely dispose of customer information no later than two years after your most recent use of it to serve the customer.” The rule text at 16 CFR 314.4(c)(6) carves out information needed for business operations, information required by law, and cases where targeted disposal is not reasonably feasible. A portal switch is the one time a firm handles every old file anyway, so it is the cheapest time to apply that rule.

Retention rules still apply to the archive. The IRS guidance on how long to keep records sets 3 years in the ordinary case, 6 years when unreported income is more than 25% of the gross income on the return, and 7 years for a worthless securities or bad debt claim. Those periods apply to the records a firm keeps, wherever it keeps them. They justify the archive. They do not justify loading it into the new portal.

A smaller new portal has one more benefit. When a client opens it for the first time and sees this year’s request and nothing else, the next step is obvious. When they see eight years of folders, it looks like a filing cabinet and they ask the firm where to put things.

How to run both portals for one billing cycle

Run them side by side for one billing cycle of the old portal, usually a month, with a strict rule about which one gets what.

From cutover day, every new request goes out from the new portal. No exceptions, including for the partner who prefers the old one. Open requests that started in the old portal finish there, unless the client has not touched them in two weeks, in which case they move to the new portal with the files already received.

During the overlap, staff do three things every day:

• Check the old portal for uploads against open requests, and copy each received file into the client’s folder in the archive.
• Answer any client who logs in to the old portal by sending them their new link, not by explaining the change.
• Tick off each client on the migration list as they make their first visit to the new portal.

That last list is the only real progress measure. The number of files moved means nothing. The number of active clients who have opened the new portal at least once is the number that tells the firm whether the switch is working.

At the end of the cycle, look at who is left. Clients with open requests in the old portal get a phone call. Clients who have not opened the new portal get one more message from a person they know at the firm, not from the system. Then close the old portal to clients, confirm the final export, and cancel.

Do not extend the overlap because a few clients are slow. A second month of two portals teaches staff that the old one is still an option, and it doubles the fee for those weeks. The slow clients will move when the old portal stops answering and the firm’s emails all point to the new link.

How to move clients to a new portal without asking them to re-register

Choose a portal where the firm creates the client and the client never signs up.

There are two ways a portal can let a client in. The first is the account model: the firm sends an invitation, the client creates a password, and from then on they sign in with an email and that password. The second is the link model: the firm sends each client a private link, and opening the link signs that client in. There is no sign-up form and no password to invent. The client still has an account, because the portal has to know who uploaded what. They just never create it.

For a migration the difference is everything. Under the account model, moving clients to a new portal means every client completes a sign-up before the switch counts for them. Under the link model, the firm imports or creates the client records, sends each client a request with their link, and the client opens it and uploads. The firm does the migration and the client does nothing new.

The link model has a cost the firm should state plainly to itself. The link is the credential. Anyone who has it can open that client’s portal, so a client who forwards the email to a spouse has shared their access. That is the same exposure a password written on a sticky note has, and for most document collection it is an acceptable one. For a firm that needs to confirm identity before a client sees a sensitive document, such as a tax return ready to sign, the portal should add a check at that step rather than at the front door.

Test the client side before cutover. Send a request to a staff member’s personal phone and complete it start to finish without help. Count the taps between opening the message and finishing the first upload. If the count includes a password field, every client will meet that field too.

How to tell clients about the switch

Tell them once, with the new link already in the message, from a sender they recognize.

Firms working out how to change client portals often send a heads-up email first. A notice with no action in it gets read and forgotten, and when the real invitation arrives a week later it looks like a second, stranger email. Send the notice and the first request as one message, at the point the client has something to do.

A message that works looks like this:

Hi Dana, we have moved to a new client portal for your documents. Your link is below. It opens your page directly, with nothing to sign up for. This year we need your W-2, your 1099-INT from the credit union, and your property tax statement. If you already sent any of these in our old portal, they have been moved over and are marked received.

Five rules hold that message together:

• It comes from the firm’s name and the client’s usual contact, not from the portal vendor.
• It says what the client has to do this time, not what the firm has changed.
• It says plainly that there is nothing to sign up for, because that is the question every client will have.
• It credits what the client already sent, so they do not think their earlier work was lost.
• It goes by text as well as email for clients who use their phone for everything, since a link in a text gets opened on the device the client will upload from.

Send in batches, not all at once. Start with twenty clients the staff know well and who will say if something is wrong. Fix what they hit. Then send the rest by group over a week, so replies arrive at a pace the team can answer. Our client document request email templates cover the wording for the follow-ups that come after this first message.

When is a client portal migration finished?

When three things are true at once. The old portal is cancelled and its final export is verified. Every active client has opened the new portal at least once. And no request in the last two weeks went out from anywhere except the new portal.

The second test catches most failed switches. A firm can cancel the old contract on schedule and still have a third of its clients sending everything by email, which means the switch did not happen for those clients, it just ended for the firm. Pull the list of active clients who have never opened the new portal and work it by phone. These are usually the clients who never used the old portal either, and for them the switch is a second chance, not a loss. A portal they can open with one tap is a better offer than the one they ignored before.

The first month on the new portal is also the time to fix the request lists themselves. A switch forces the firm to look at every template it sends, and most firms find requests that ask for documents nobody reads. The client document checklist for before work starts is a good place to compare. Shorter requests get finished, and a finished request is how the client learns the new portal works.

If the reason for the switch was that clients would not use the old portal, read why client portals fail before picking the new one. The causes it names are the same ones that sink migrations: a login the client has to manage, notices that do not lead straight to the task, and staff who route around the tool when it is slow.

Where zendoc fits in client portals

zendoc is a client portal built on the link model. Each client gets a unique link that signs in only that client, with no signup form and no password to create, and the link arrives by SMS and email with the request already inside it. A firm that moves to zendoc creates the client and sends the first request, and the client’s first visit is the upload itself. Requests are built from reusable workflow templates that hold forms, document uploads and e-signatures in one link per client, and the firm sees per-step completion for every client during the overlap. Plans are flat per firm rather than per seat, listed on the pricing page, and you can see how it works on the zendoc home page.