Running two assistants during a switch
There is a window where you are paying for two assistants at once. Most people either skip it and discover the gaps after cancelling, or drift through it for months because no moment ever feels like the right one to commit.
Both failures have the same cause: the parallel period was never given a job or an end date. It needs both.
What the period is for
Not for comparing quality. That question was settled when you decided to switch, and re-opening it during a fortnight when one assistant has a year of accumulated context and the other has none will give you a misleading answer anyway.
The period exists to find the things you did not know you relied on. Every one of those is specific, boring, and invisible until the moment you need it: a document format that came out right without asking, a workflow that depended on a connected account, a kind of task you do twice a month and forgot to think about.
You cannot enumerate these in advance. That is precisely why the period exists.
Set the end date first
Pick it before you start, and pick it off your billing cycle rather than a feeling.
The natural shape is to run in parallel until a few days before the old subscription renews, then decide. That gives you a real deadline, avoids paying for an extra month of an account you have stopped using, and leaves a margin for the export and cancellation sequence to be done unhurried.
One to two billing cycles is usually enough. Longer than that and you are not verifying, you are avoiding the decision — and the cost is not only the double subscription. Splitting your work across two assistants means neither accumulates context, so both feel worse than either would alone. The parallel period is a diagnostic, and running a diagnostic indefinitely is its own failure.
Send real work to the new one, by default
The rule that makes the period work: the new assistant is the default, and the old one is the fallback. Not the other way around.
If you keep using the old one for anything that matters and the new one for experiments, you will reach the end date having learned nothing. The gaps only surface under real conditions — real deadlines, real documents, the tasks you do without thinking.
So: new assistant first, every time. When it does not work, note what did not work, then finish the job on the old one. That note is the entire output of the exercise.
Keep the list of what broke
One file. Append a line whenever you fall back, with enough detail to act on:
- what you were trying to do
- what went wrong, specifically
- whether you fixed it, worked around it, or gave up
After two weeks this list is the only thing you need to make the decision, and it separates into three kinds of entry.
Fixable by instructions. The output was wrong in a way a standing instruction addresses. Most early entries are this, and they thin out fast once you update the instruction file.
Fixable by habit. You asked in a way that worked on the old assistant and does not on this one. Also common, also temporary, and genuinely your adjustment to make rather than a defect.
Not fixable. A capability is absent, an integration does not exist, a format is not supported. These are the only entries that matter for the decision, and there are usually far fewer than the first two weeks suggest.
Test the tasks you do rarely
The gaps that hurt are in the monthly work, not the daily work. Daily work exercises itself; a task you do every few weeks will not come up during the parallel period at all, and will surface later when the old account is closed.
So run them deliberately. The expense report, the recurring report format, the quarterly document, the thing you only do when a particular colleague asks. Go through the last two or three months of your own history and find the tasks that appear once — those are the test set, and working through them takes an hour.
This is the single highest-value hour in a switch, and it is the one everybody skips.
What moves
WHAT MOVES — the parallel period
· Real work sent to the new assistant
→ produces the only reliable list of
what actually breaks
· Tasks you do daily
→ test themselves. No effort needed.
· Tasks you do monthly
→ STAYS BEHIND untested unless you
deliberately run them. This is where
the expensive surprises live.
· Accumulated context on the new side
→ STAYS BEHIND while you split work
across two. Both feel worse than
either would alone.
· The old assistant's shared links and
integrations
→ still live during the period. Replace
and revoke before the end date, not
after.
· Letting the period run past the renewal
date
→ costs a cycle and decides nothing.
Set the end date first.Deciding at the end date
Look at the list, and only at the not-fixable entries.
If it is empty, the switch is done and the remaining work is administrative. If it has one or two entries, the question is whether a workaround is acceptable — and it usually is, because you have been living with those workarounds for a fortnight already and know exactly what they cost.
If it is long, that is real information, and worth taking seriously rather than pushing through. A switch that fails at this stage costs you a double subscription for a month or two. A switch you force through anyway costs you the thing you switched away from, permanently, and you find out afterwards.
Either way the decision belongs to the list, not to how the fortnight felt. The feeling is unreliable for a reason that is now well understood: you spent it comparing a tool that knew you against one that did not.
Then do the irreversible part carefully
Once you have decided, the parallel period is over and the sequencing becomes the only thing that matters. Export, verify, replace shared links, revoke integrations, cancel — in that order, with the export verified before anything is cancelled.
None of that is difficult. It is only unforgiving, which is a different problem.