How to Change Something People Already Paid For

Published August 1, 2026

Part of: Digital Products — our full guide on this topic.

Disclosure: Some links below are affiliate links. If you sign up through them we may earn a commission at no extra cost to you. We only recommend tools we'd genuinely suggest to a friend. See our full disclosure.

There is a family of articles on this site about things ending. A platform can close down underneath you or remove you specifically. You can close the whole business, take a finished product off sale, or close a membership other people are still paying for.

This one is not an ending. You are keeping the thing. You are changing it — moving a course to a different platform, replacing a PDF workbook with a web version, merging three tiers into two, dropping a feature nobody seemed to use, renaming the whole business — while people are inside it, mid-way through, and still being billed.

It is worth separating from the article next door. Updating a digital product is about a finished file that the buyer already holds, and every category in it — a correction, an addition, a rebuild — is something the buyer can take or ignore with nothing lost either way. That is not this. The test that separates them is not how big the change is. It is whether anything they already had stops working.

And here is the structural fact that makes this its own job. An ending has a date after which you owe nothing. A change has no such date. What a change does is fork your obligation: from the moment you make it there are two populations — the people who came in under the old thing and the people arriving under the new one — and you own both of them until you deliberately close one. Nobody sends you a reminder about that. The bill just arrives, quietly, for years.

The site already says this out loud, but only about price. Raising your prices puts it exactly right — holding existing members at their old price is good advice; it is also not free, and the bill arrives years later — and then, reasonably, goes back to talking about price. The same sentence is true of every feature, format, platform and promise you decide to hold for the people who were already there.

The quick version

• Sort the change by what it costs them, not by what it costs you. Three categories, and only one of them can actually fail.
• If the change requires them to act, some of them will not act — and that is arithmetic, not a failure of your email. Decide what happens to those people before you announce.
• Write down what stops working. If you cannot name a single thing, you have not looked hard enough. Every change removes something.
• What you owe is set by what you sold, not by how much better the new thing is.
• Every version you keep is a version you maintain forever unless you put a date on it at the moment you announce it.
• Leave a sign at the old address. The person who matters most missed both your emails.
• Change one thing, then wait a full billing cycle. Otherwise you cannot tell which change moved the number.
• Do not delete the old thing — the old plan, the old page, the old file — until the change has been through one complete cycle.

Sort the change by what it costs the other person

The instinctive sort is by how much work the change is for you: small tweak, big project, complete rebuild. That sort tells you how to plan your week and nothing at all about how the change will land.

The sort that matters has three categories, and they are defined entirely by what the person on the other side has to do.

1. Invisible. They would never know unless you told them. You moved your files to different storage, swapped the tool that sends the receipts, rewrote the back end of a page whose address and appearance did not change. Nothing is required of anyone. There is no announcement to write, and writing one anyway is a small act of self-indulgence that turns a non-event into an event.

2. Visible, but nothing to do. The thing looks different, is organised differently, has a new name on it, gained something or lost something they were not using. They will notice; they do not have to act. This is where most changes live, and it is where the whole job is telling people well.

3. It requires an act. They have to log in somewhere new, create a password, re-download something, move their own material across, re-add a payment method, re-book a recurring slot, accept new terms, install something. Anything at all that only works if they do a thing.

That third category is the only one that can fail, and the failure has a specific shape worth understanding before you design the change.

The people who never act

If a change requires an act from four hundred people, some number of them will not perform it. Not because they object, and not because your email was bad. Because a proportion of any list is not reading their email this month, a proportion is reading it on a phone in a queue and meaning to come back, a proportion has your address filtered into a folder they check quarterly, and a proportion has simply forgotten they are subscribed to this at all until the charge appears.

You cannot write your way out of that. It is not a communication problem with a communication solution; it is a structural property of asking a group of humans to do something. So the useful question is not how do I make sure everyone acts? It is:

What happens to the ones who never act?

Answer that on paper before you announce anything, because the answer is the actual design of your change.

The best answer is that the old thing keeps working, and the act buys them the new thing. The download link in their inbox still resolves. The old login still gets them in. Acting is an upgrade, not a rescue. Under this design the people who never act are simply people who have not upgraded yet, and they can do it in eight months when they finally open the email, and nothing bad has happened to anybody.

The worst answer is that the act is a prerequisite for continued access, with a deadline. Now the people who never act lose the thing they paid for, and you find out about it in ones and twos over the following year, each time as a support message from somebody who is upset and correct.

Most of the time you can move a change from the second design to the first by keeping something small alive — a redirect, a page that still loads, a link that still resolves to the file. It usually costs less than the support load it prevents. Where you genuinely cannot, at least know that you have chosen the expensive version, and hold some capacity back for the tail of confused arrivals.

Write down what stops working

Ask what your change removes, and keep asking until you have at least one honest answer. If your list is empty, you have not looked; you have described the change from the inside, where it is obviously an improvement.

Take the most common one. We have moved everything into the new member portal — it is all in one place now, much easier to find. From your side that is unambiguously an addition. From the other side, several things just stopped working:

• The bookmark that went straight to the thing they use.
• The copy they downloaded and keep in a folder, which is now the old version of something they are told is elsewhere.
• The ability to skim the whole thing on one page, if the new structure is a menu of sections.
• Whatever route they had memorised to get to the bit they actually use, which is now three clicks in a place they have never been.
• The printed copy, for the people who print things.

None of that means do not move to a portal. It means those five items are the content of your announcement and possibly the content of your design — and that a change which reads as tidier for me frequently reads as harder for you on the receiving end. The gap between those two readings is where almost all the resentment about product changes comes from, and it closes the moment you name the losses yourself instead of waiting for someone else to.

There is a general version of this worth carrying. You are not changing a feature. You are changing something people have arranged themselves around. The feature is yours; the arrangement is theirs, and it is invisible to you.

What you owe is set by what you sold

Now the boundary that decides the hard cases, and it is not about the size of the change.

If your sales page promised something specific — a format, a feature, a number of calls a month, a particular kind of access — then removing that is a failure to deliver what was bought. It stays a failure to deliver even if the replacement is better, faster, more modern and unanimously preferred by everyone who has tried it. Better is a judgement about the product. What was sold is a fact about a page you published, and the person who read that page is entitled to it.

So the first question in any contested change is not “is this an improvement?” It is: what did the sales page actually say, and is it still true afterwards? Go and read it. Not from memory — the wording is usually more specific than you remember, because you were selling when you wrote it.

Where the answer is that the change breaks something you promised, there are three honest positions:

• Keep the old thing available to the people who bought it, and let the new thing be the version everyone else gets.
• Offer a refund to anyone for whom the change genuinely breaks the purchase — proactively, in the announcement, not grudgingly when they complain. A refund you offer costs the same money as one you concede and buys something the second one never will.
• Do not make the change, or make a smaller version of it that does not break the promise.

And one dishonest position, which is to announce it as an upgrade and hope nobody rereads the page. That works right up until one person does, and that person writes a review you will find much harder to answer than the original problem.

Where you promised nothing specific, you have real latitude, and the question stops being obligation and starts being cost. Which is the next section.

One note that belongs here because it is where the promise is usually made: lifetime updates and lifetime access are, as the updating guide sets out, promises with no end date and no stated whose-lifetime. If your wording is ambiguous, buyers read the generous version, and they are not being unreasonable — you wrote the sentence and they only read it.

The fork: every version you keep, you keep forever

Say you decide, generously and correctly, that existing members keep the old thing. The calls stay on the old day for them. The PDF stays downloadable for the people who bought it as a PDF. The three old tiers stay alive for whoever is on them while new buyers see two.

You have just created a second product. It has no sales page and no revenue attached to it, and it will need testing every time you touch the shared parts, and in two years you will not remember why one of your members is on a plan that does not appear anywhere in your dashboard.

This is not an argument against grandfathering. It is very often the right call, and it is the default recommendation for price for good reasons. It is an argument for making the decision explicitly, at the moment you announce, between two options:

• Indefinitely. You are carrying this version for as long as those people stay. Fine — as long as you have said it to yourself and can still say it out loud in five years.
• Until a stated date. “The old format stays available until the end of March next year.” A boundary you name in the announcement is accepted almost without comment. The same boundary introduced later, once people have settled into believing the old thing is permanent, is a second change with a second announcement and considerably more friction.

Saying nothing is not a third option. It is choosing indefinitely without noticing that you chose.

Two practical notes. First, check what your platform can actually do before you promise either — the pricing guide makes this point about legacy price plans, and the same uncertainty applies to feature access, old tiers and grandfathered permissions. Some tools hold a legacy state cleanly, some apply a change to everyone on the plan, and it is not always documented where you would look first. Test it on a spare account or your own subscription rather than assuming. Second, if you keep an old version alive, write down somewhere durable that it exists and who is on it. The failure mode is not that you decided wrongly; it is that in eighteen months nobody remembers the decision was made.

Sequencing: one thing, then a full cycle

There is a strong temptation to bundle. You are already going to upset people, so you may as well migrate the platform, restructure the tiers and rebrand at the same time and take the hit once.

The reason not to has nothing to do with how much people can absorb. It is that bundled changes are unreadable. If cancellations rise next month, you have three suspects and no way to separate them, which means you cannot reverse the one that caused it. The subscription metrics that would tell you only tell you anything if one variable moved.

So: one change, then a complete billing cycle, then look at the number, then the next change. It is slower and it is the only version where you learn anything.

The second reason to unbundle is that reversibility is not uniform, and you should know which of your changes are which before you announce any of them.

• Reversible in an afternoon: the sender name on your emails, the layout of a page, the name of a tier, a description, which day the call is on.
• Reversible but awkward: a platform migration where you still hold the old account. Doable, embarrassing, survivable.
• Effectively permanent: deleting an old plan from your payment processor — you often cannot recreate it and put people back on it at the price they were on. Letting a domain lapse, which is the one genuinely irreversible step in any wind-down. Deleting the only copy of an old file. Cancelling the old tool and losing the export window with it, which is exactly the situation backing up your business exists to prevent.

Which gives the single most useful safety rule in this article: do not delete the old thing until the change has been through one full cycle. Not the old plan, not the old page, not the old file, not the old account. Keeping them costs almost nothing. Needing one back after you have deleted it costs an amount you cannot predict in advance.

People who are mid-way through

Any change to something with a sequence in it — a course, a cohort, an onboarding flow, an email series — has a group of people standing in the middle of it when the change lands. They are on lesson four of twelve, or email three of seven, or week two of a six-week thing.

Moving them mid-flight is the version that goes wrong, because their position is the state you are most likely to lose. The email automation guide has the right instinct and states it for sequences specifically: build the new one alongside, point the trigger at it, and let the old one drain — leave it running for anyone already inside, then switch it off once it is empty.

That generalises to almost everything with a middle. Stop new people entering the old thing, and let the old thing empty on its own, rather than lifting people out of it. It costs you a period of running two versions, which you were probably going to do anyway, and it removes the entire category of problems that begins with somebody losing their place.

Where draining genuinely is not possible — a platform that is going away, a cohort that cannot continue — then the people mid-way through are not a group to be migrated, they are a group to be contacted individually. There are never very many of them, and an email that says you were on week three, here is exactly where that is in the new place is fifteen minutes of work that prevents the only complaints this change was ever going to generate.

Writing the announcement

The announcement for a change is not the announcement for a price rise and should not be built the same way. A price announcement leads with the number and the date, because that is the only thing anyone wants to know. A change announcement leads with something different, because the reader’s question is different.

The reader has exactly one question, and it is: does this affect me, and do I have to do anything?

So answer it in the first two lines, before the reason, before the context, before anything about how excited you are. If the answer is nothing changes for you and there is nothing to do, that sentence is the email, and it is one of the more welcome things a person can receive from a business they pay.

A structure that works:

1. What is changing, in one sentence, in the reader’s terms rather than yours. Not “we are migrating to a new platform” but “the course is moving to a new site, and your login will be different.”
2. What you need to do — including, prominently, nothing, when that is true. If there is an action, make it one action with one link, not a list.
3. When. A date, not “soon”.
4. What is not changing, especially anything they might reasonably fear. Price, access, what they already downloaded.
5. What you are losing, named by you. This is the paragraph most people cut, and it is the one that determines whether the email reads as honest or as marketing.
6. The reason, briefly, last. It matters less than you think and it is not what they are scanning for.

Two distribution points. Send it to the people it affects — the price guide is right that broadcasting a change to a large group who are not affected generates people wondering whether they are, and some of them will use the moment to reconsider a subscription they had not been thinking about. And send it more than once: when you decide, and again as it happens. Those are two different audiences even though they are the same list, because the second send catches the people for whom the first one arrived during a busy fortnight.

Leave a sign at the old address

Everything above is about the people who read your emails. The person who actually generates the problem is the one who did not — who has not opened anything from you since March, likes the thing, pays for it quietly, and turns up in six weeks at a URL that no longer exists.

No notice period reaches that person. A sign at the old address does.

• The old link should not 404. Redirect it, or leave a page there saying where the thing went, with a link. This is the same discipline as not breaking your URLs when you restructure a site — the addresses people have saved are an asset, and they do not stop mattering because you have moved on.
• The old login screen, if you control it, should say where the new one is rather than just refusing the password.
• Pin the change somewhere it stays visible: the top of the members’ area, the group, wherever people arrive.
• Keep the sign up far longer than feels necessary. The tail on this is long. Someone will arrive next year.

This is a genuinely small amount of work and it is the difference between a person finding a helpful note and a person concluding that the thing they pay for has vanished. The second one does not usually email to ask. They just cancel.

The bottom line

An ending is a date. A change is a fork, and you own both branches until you close one on purpose.

Sort the change by what it costs the people on the other side rather than by what it costs you; if it requires them to act, design for the ones who never will; name what stops working before someone else does; check what you actually sold before deciding what you owe; put a date on any old version you agree to keep; change one thing at a time and keep the old one intact for a cycle; and leave a sign at the old address for the person who missed every email you sent.

Do those, and most changes pass with a couple of replies saying thanks for the heads-up. Skip them, and a change you were right to make becomes the reason a quiet, paying, perfectly happy member decides they are done.