工具或平台調漲價格後，轉換前要核實的六項假設

A price change has a way of turning a calm tool into an urgent project. A theme framework drops its cheaper tiers and sells only per-site plans. A course plugin gets folded into a hosting bundle. A course platform's top plan suddenly costs several times what it did. A community platform adds a fee to every member renewal. An automation service charges per task, and the bill grows with every workflow you add.

Across the communities we follow, the reaction looks the same each time. Some people start planning the move the same evening. Freelancers start offering migration services. Others build their own replacement with an AI assistant over a weekend. And a quieter group sits down, reads the new terms twice, and renews.

We've helped a lot of site owners through these moments, and we keep seeing the same assumptions come up. Some hold. Most need checking first.

1. "We have to decide before the renewal date"

Usually not quite. Most renewals don't switch anything off on the day. You'll often have a window where the current version keeps working, even if updates and support pause. That window is worth knowing exactly, because it turns a panic into a plan.

What we'd check: does an expired licence stop the plugin working, or only stop updates? Is there a grace period? Can you renew for one more year at the old price while you test something else? Several people in these discussions found they had more time than the email suggested.

2. "Moving is mostly about the content"

This is the one that bites. Content usually moves. Lessons, posts, listings and pages tend to come across with an importer or a few hours of copy and paste.

What doesn't move as easily is the logic around it. One site owner leaving a course plugin had 25 courses that all relied on group enrolment codes, and the importer they were looking at skipped groups entirely. Others found the same with certificates, coupons, past orders, drip schedules and member permissions. Before you price a move, list the things your site does, not just the things it holds.

3. "Building our own will be cheaper"

Sometimes, for the first month. We understand the pull. One creator left a course platform costing a few hundred a month and built a custom lesson site instead. Others are building with AI help and are genuinely pleased with the first version.

The cost shows up later, in the edge cases: failed card renewals, someone who needs re-enrolling, a certificate reissued with a corrected name, a refund that should remove access, a security update nobody scheduled. If you build, budget for year two, not just launch week. If you don't want to own those edge cases, that's a very good reason to pay someone who does.

4. "Self-hosted means free"

Self-hosted means you pay differently. People moving off per-task automation pricing make a fair point: running the same workflows on your own server can cost far less. But someone now owns the retries, the logs, the failure alerts and the 2am "why didn't that email send?" That someone is usually the person who suggested the move.

Self-hosting is often the right call. Just write down who handles failures before you switch, so it isn't decided by whoever notices first.

5. "Everyone is leaving, so we should too"

Loud isn't the same as most. Price changes produce a lot of noise, and the angriest posts travel furthest. Many people quietly renew because the tool still fits and the switching cost is higher than the increase.

A useful exercise: work out what the new price costs you per member, per student or per client site, then compare it with what a move costs in hours. Sometimes the increase is a rounding error. Sometimes it changes your margins completely. Agencies with many client sites on per-site licences tend to feel it most, which is why they're often the first to move.

6. "The next tool won't do this to us"

Any tool can change its pricing. That includes the one you move to, and it includes ours. What you can control is how painful the next change would be.

The habits that help are boring ones. Keep your data in formats you can export. Keep payments in an account you own, so money doesn't sit with a middleman. Avoid features that only exist inside one vendor's world unless they're worth it. Keep a short document of what your site depends on. That way the next renewal email is a decision, not an emergency.

A simple order of work

When a price change lands, this is roughly the order we suggest:

1. Read the new terms and find out exactly what stops on the renewal date.
2. Work out the real yearly difference for your setup.
3. List what your site does (enrolment rules, payments, permissions, automations), not just what it stores.
4. Test one alternative with a copy of real data, including the awkward parts.
5. Decide with the full cost of moving in front of you, including your own time.
6. If you move, move in stages and keep the old setup readable until you're sure.

None of this needs to happen in a weekend.

Your turn

• When a tool you rely on raised its price, did you move, renew, or build your own? Would you make the same call again?
• What turned out to be the hardest thing to migrate, the part nobody warned you about?
• For those who built a replacement themselves: what broke first, and how long after launch?
• How do you work out whether an increase is worth the effort of moving: per seat, per site, per hour of your time, or gut feel?