Atlas
  • All-in-one
  • Solutions
  • Compare
  • Pricing
PricingGet started
  1. Atlas
  2. Guides
  3. Moving Client Management Off Spreadsheets and Email
August 15, 2026·11 min read·Client Management, Operations, Migration

Moving Client Management Off Spreadsheets and Email

The spreadsheet is not the problem. The problem is that it is the only place three facts exist and nobody knows which three.

Almost every professional services firm runs client delivery on a shared mailbox, a workbook and a folder structure, and it works far longer than anybody expects. It stops working at a specific and recognisable point: when the number of people who need to know something exceeds the number who happen to be on the thread.

The migration away from it is usually attempted as a technology project and usually fails as a change project. What follows is a sequence that treats it as the latter.

Recognising the point at which it has stopped working

The symptoms are behavioural rather than technical, and they are worth naming because firms tend to normalise them.

  • Somebody has to search their own mailbox to answer a factual question about a client commitment.
  • Two people give a client different answers about the same deadline in the same week.
  • A person going on leave requires a handover document that takes half a day to write.
  • A client asks what was agreed in a meeting three months ago and the answer requires an archaeology exercise.
  • The workbook has a column somebody is afraid to change because they do not know what depends on it.
  • Onboarding a new joiner takes longer than a month before they can answer a client question unaided.

What to migrate, and what to leave behind

The instinct is to move everything, and it is wrong. A migration that carries fifteen years of history into a new system reproduces the mess in a more expensive place, and it makes the new system feel like the old one on day one, which is fatal to adoption.

Move what is live and what is legally required. Leave the rest where it is, archived and searchable, and let it age out.

  • Move: live engagements, current commitments, open risks and issues, the client contact list, and contractual documents still in force.
  • Move: anything with a retention obligation, which usually means signed agreements, approvals and formal correspondence.
  • Leave: closed engagements older than your retention floor, superseded document versions, and the entire mailbox.
  • Leave: the workbook itself, read-only, for a defined period. People will check it, and telling them not to does not stop them; making it read-only does.

The sequence that works

Run it engagement by engagement rather than all at once. A big-bang cutover in a services firm means every client relationship changes on the same day, and any problem affects all of them simultaneously.

  • Pick one engagement with a tolerant client and a willing lead. Not the largest, and not the most difficult.
  • Move that engagement completely. Half-migration is worse than none, because it creates two places to look, which is the original problem.
  • Run it for one full reporting cycle, so the monthly report, the billing run and at least one governance meeting all happen in the new place.
  • Write down what broke. Fix the process, not just the instance.
  • Then move engagements in batches, oldest and simplest first, with a fixed date after which the old place is read-only for each batch.
  • Set a firm-wide date for the shared mailbox to become read-only, announce it well in advance, and hold it. A migration with no end date does not end.

The part everybody underestimates: telling the clients

A migration changes how clients interact with you, and a client who learns about it from a system-generated invitation email will treat it as spam. This is the single most common cause of a portal rollout stalling at low adoption, and it is entirely preventable.

Tell each client individually, from a person they know, before any automated message arrives. Say what changes for them, what does not, and what problem it solves for them specifically rather than for you. A message saying it will improve our internal efficiency invites the reasonable response that this is not their concern.

Give them a way back. A client who cannot get an answer because they cannot log in will email, and if the email goes unanswered you have made their life worse in exchange for making yours better, which is how goodwill is spent.

Keeping the history without carrying the mess

History matters in professional services because a question about what was agreed can arrive years later, and the answer has commercial consequences. But history does not need to be in the working system to be findable.

The workable arrangement is a frozen archive with a documented index: where the old material lives, who can reach it, how far back it goes, and when it will be deleted under the retention policy. One page, written once, kept with the client records. It costs an afternoon and it is the difference between an archive and a pile.

Measuring whether it worked

Decide the measurements before the migration starts, because afterwards everybody will have an opinion and no baseline. Three are usually sufficient.

Time to answer a factual client question, sampled the same way before and after. The number of client-facing commitments with a named owner and a date, which should rise sharply because the old system had no way to enforce it. And the proportion of client interactions happening in the new place rather than by email, which is the honest adoption number and the one most firms avoid looking at.

Keep reading

  • A Phased Migration Plan From Point Tools to One Platform
  • How to Build a Tool Migration Checklist
  • Data Migration Best Practices for Work Tools
  • How to Migrate from a Spreadsheet to a Work OS
  • How to Migrate to New Software Without Disrupting the Business
  • How to Plan a Phased Migration Between Work Tools
  • Free PDF tools
  • The all-in-one work OS

FAQ

Questions, answered.

How long does a migration like this take?
For a firm with dozens of live engagements, plan on one quarter from the pilot engagement to the shared mailbox becoming read-only, with the pilot occupying the first four to six weeks on its own. Firms that compress it below that generally skip the pilot cycle, and the problems that the pilot would have found instead appear across every engagement at once.
What do we do about email that keeps arriving?
Accept that it will and design for it rather than fighting it. Route the shared mailbox somewhere a person still reads, and make the standard response a short note recording the substance in the new system and a link to it. Clients learn the pattern within a few exchanges, and it is far more effective than asking them to stop emailing.
Should we migrate closed engagements?
Only where a retention obligation or a live dispute requires it. Closed work carried into a new system is dead weight that makes every list longer and every search worse, and the argument for moving it is almost always a fear of losing something rather than a use for it. A documented archive answers that fear at a fraction of the cost.
The team is resisting. What actually helps?
Find out what the old way did well, because resistance is usually a rational response to losing something real. A shared mailbox is fast, requires no training, and lets a person see everything at once. If the new system is slower for a common task, that is a defect to fix rather than a change to manage, and treating it as the latter is why migrations stall.

Ready when you are

One workspace, not ten.

Atlas replaces the stack with one platform for tasks, projects, CRM, contracts, e-signature, PDF tools, and analytics. Start free.

Get started freeSee pricing
AtlasWork, planned itself.

The AI-native, all-in-one work platform. Tasks, projects, CRM, contracts, and analytics in one calm workspace.

All systems operational
  • SOC 2 II
  • ISO 27001
  • HIPAA
  • GDPR

Product

  • Overview
  • PDF tools
  • Diagram tools
  • People & HR
  • Integrations
  • Marketplace
  • Pricing

Resources

  • Guides
  • Glossary
  • Compare
  • Docs
  • API reference
  • Support
  • Changelog
  • Status

Company

  • About
  • Careers
  • Press
  • Contact

Legal & trust

  • Trust center
  • Security
  • Privacy
  • Terms
  • DPA
  • GDPR
  • SLA
  • Refunds
  • Google API data
Atlas, a product by wrxstack.com·© 2026 wrxstack·All rights reserved
PrivacyTermsSecurityStatus