I’d announce a pricing change with three facts: what changes, who is affected, and when enforcement starts. Give developers time to test, get budget approval, and move workloads - not just time to read an email.
My checklist covers four parts:
- Explain the change: Publish exact deadlines and time zones, eligibility rules, and the business reason.
- Protect current users: Define grandfathering, credits, or a grace period, including when each ends.
- Show the next steps: Give each affected resource a migration path, export instructions, and an “If you do nothing” explanation. Separate service interruptions from data deletion.
- Track the transition: Notify affected accounts directly, answer policy questions publicly, and keep one policy page current. Measure completed migrations - not announcement clicks.
For context, Docker’s 2021 subscription change gave affected users five months before paid subscriptions were required. Your timeline should reflect the work users need to finish.
I’d treat enforcement as a checkpoint, not an automatic deadline: resolve conflicting instructions and data-loss risks before proceeding.
1. State what changes, who is affected, and when
Publish one official announcement and reuse it across account notices, billing docs, and migration guides. Before launch, check that plan names, eligibility rules, deadlines, and enforcement language match everywhere. Assign one owner to keep the notice current.
Clear details reduce surprises and help users trust the rest of the migration. Once the notice leaves no room for confusion, explain why the change is happening and what protections users get.
Distinguish pricing, eligibility, usage, and data changes
Separate pricing changes from access changes. Label each change to prices, included usage, rate limits, free-tier eligibility, features, and service availability. Spell out whether deployments, API access, scheduled jobs, or stored data will change. Link directly to the relevant pricing terms, eligibility policy, migration steps, and support contact.
Give separate dates for new terms, billing, the end of the grace period, access restrictions, and data deletion. Include the exact time and time zone for each deadline, and say whether it applies to an account, workspace, or organization. Clearly state the export deadline and how long data will be retained.
Define eligibility and the grace period
Docker Desktop’s 2021 announcement preserved free access for small businesses with fewer than 250 employees and less than $10 million in annual revenue. The updated terms took effect August 31, 2021, with a January 31, 2022, deadline for paid subscriptions.
Use the same structure for your policy so users can check their status without opening a support ticket.
Make eligibility easy to check. Explain which thresholds apply and how teams can verify their status before deploying or renewing. State whether legacy contracts or new accounts follow different rules.
Include the grace period in the first announcement, along with what stays available during that period and what happens afterward. Developers shouldn't need support to confirm eligibility or deadlines.
2. Explain the reason and protect users during the change
After announcing what’s changing and when, explain why it’s happening and how users will be protected.
Name the verified constraint - not just the business goal. That might be support load, the cost of keeping the service running, or usage costs. Developers need this context to assess their budgets, migration work, and data risks. For help structuring the offer, see developer-tool pricing strategy, free tiers, and enterprise contracts.
Be clear about what stays the same, including paid-plan features, API behavior, data ownership, security controls, and contractual commitments. If only free-tier eligibility changes, say so. Don’t promise “nothing else changes” until you’ve checked billing, integrations, and exports.
Choose grandfathering, credits, or a grace period
| Option | Customer benefit | Cost to deliver | Implementation risk | Required communication |
|---|---|---|---|---|
| Grandfathering | Keeps existing terms for eligible users | High over the long term | Medium, because legacy rules need maintenance | Define eligible accounts, covered features, duration, renewal treatment, and exceptions |
| Temporary credits | Covers some initial costs | Medium | Medium, especially when reconciling billing and usage | State the credit amount or formula, expiration date, eligible usage, and what happens when credits run out |
| Grace period | Gives users time to test and migrate | Low to medium | Low to medium | Publish start and enforcement dates, reminders, milestones, and consequences of taking no action |
| Paid-plan conversion | Prevents interruption when conversion is safe | Medium | High if billing, limits, or resource behavior changes automatically | Explain the destination plan, billing start date, limits, cancellation rules, and required account action |
| Shutdown | Ends a service or resource that can’t be maintained | Low after completion, but high during the transition | High because data loss or outages are possible | Provide export tools, final deadlines, deletion rules, backups, and support boundaries |
Base protection on account status or resources that exist on the announcement date. Explain whether new resources qualify, when protection ends, and what happens to unused credits. Publish the rules for exceptions and extensions, too.
If you’re retiring a free tier, explain the workload and data effects separately.
State the impact of retiring a free tier
Tell users which workloads will stop, which data is at risk, and whether they need to act to convert. Provide a supported export option or a path to a paid plan. Separate loss of access from data deletion, and state when recovery will no longer be possible.
On August 25, 2022, Heroku announced that free Dynos, free Heroku Postgres, and free Heroku Data for Redis would no longer be available beginning November 28, 2022, citing a focus on “mission-critical capabilities for customers.”
Then give affected developers the exact migration steps.
3. Give developers clear migration steps
Turn the notice into a migration checklist for each resource. Once the policy is public, map every affected workload to a paid plan, a remaining free option, or an export path. Cover compute, databases, storage, scheduled jobs, authentication, and integrations separately.
For each resource, list the required action, prerequisites, deadline, verification test, and consequence of doing nothing. Give each team a clear role: product and engineering verify behavior, billing confirms enforcement, support answers questions, and documentation keeps instructions current.
Cover testing, exports, and what happens without action
Ask developers to test outside production. They should check billing, permissions, authentication, deployment configuration, integrations, scheduled jobs, and any API compatibility or limits affected by the migration.
For persistent data, spell out the export format, download deadline, retention window, and test restore. Where rollback is supported, explain what triggers it, how to perform it, and what happens to data written after migration.
Heroku’s transition guidance distinguished free Dynos converted to Eco Dynos and scaled to zero, free databases subject to deletion for certain accounts, and Scheduler jobs that would fail until reconfigured to another Dyno type.
Put “If you do nothing” near the top of each migration path. State whether existing workloads stop or scale to zero, new deployments fail, billing starts, or data becomes unrecoverable. Restarting compute and restoring deleted data are different tasks. Explain them separately.
Notify affected accounts before broader distribution
Send the checklist to affected accounts before any broader announcement. Start with direct email and account notices, then send deadline reminders and a final enforcement notice.
Include the affected resources, required steps, cutoff time zone, billing effects, support contact, documentation links, and a way to confirm completion.
If you need to reach more people, supplement customer notices with daily.dev Ads, targeting by tech stack, seniority, geography, and interests. Link to the migration guide, and measure completed migrations separately from ad engagement. Keep advertising secondary to direct customer notices.
4. Answer publicly and track the transition
Once migration steps are live, use one canonical policy page as the source of truth for updates, questions, and enforcement status. Add a visible last-updated timestamp and dated change log. Link every notice and public reply to that page.
Assign owners for policy accuracy, public replies, billing, and support escalations. Name backups for weekends, launch windows, and enforcement milestones. Answer eligibility and deadline questions publicly. Move account-specific billing amounts, contract terms, usage records, refunds, credentials, exports, and sensitive product data to authenticated support.
Clarify policies and measure migration progress
Unity revised its policy in 2023, then canceled the Runtime Fee for gaming customers effective September 12, 2024.
After publishing the notice, track whether accounts are moving. Report completed migrations, incomplete migrations, and migrations not yet started as both counts and percentages of affected accounts.
Define completion with a verified event, such as a successful plan conversion or a passing integration test. Then reconcile product, billing, and support records. Review unresolved tickets, failed exports, billing disputes, and cancellations before enforcement.
Conclusion: check the transition before enforcement
Before each enforcement milestone in 2026, verify the affected-account list, dates and time zones, rationale, grandfathering terms, migration steps, data consequences, and support ownership. Check that every notice, help doc, and support reply matches the canonical policy page.
Delay enforcement if material contradictions or unresolved data-loss risks remain. Use the policy page and support queue to resolve those issues before enforcement starts.
If broader distribution helps developers find the update, use the schedule link as a secondary channel.
FAQs
How much notice should we give developers?
Set your notice period around how much work customers need to migrate, not your launch calendar. Give users plenty of notice. Contact high-value integration owners first, then reach other users through direct email and in-product notices.
If you’re changing prices or cutting the free tier, consider keeping current users on their existing terms for 6 to 12 months to help maintain trust. Before any public announcement, test every migration path, rollback, and set of support instructions so users don’t get blocked during the transition.
How do we choose who gets grandfathered?
Consider keeping all existing customers at their current rates for at least 6 to 12 months, rather than reserving that option for high-value accounts. This helps maintain trust, lower churn risk, and give customers time to adjust - without making smaller users feel less valued.
Announce the change early and explain why it’s happening. Clearly state which accounts qualify and when their current rates will change.
How should we handle unreachable account owners?
Put security and service continuity first. Contact secondary administrators or billing contacts already linked to the account. If they don’t respond, notify active users in-product about the pending ownership transfer. Explain how they can verify their authority to claim administrative access.
Record all outreach and verification attempts to help prevent account takeovers by people without permission. Rather than suspending the account immediately, restrict administrative functions while keeping standard account activity running. Set a clear timeline for claiming the account.