The 27-step CodeCanyon exit checklist

The whole thing, free, full text, no signup, no email wall. This is the genuine DIY route for moving a CodeCanyon/Envato-sold WordPress plugin off Envato and onto Freemius (or your own store). Follow it and you can do this yourself over a focused weekend or two. Where the paid service actually adds something, this page says so plainly — and where it does not, it says that too.

Scope note: this guide assumes a self-contained premium WordPress plugin currently sold on CodeCanyon with Envato purchase-code licensing. Themes, bundles, and SaaS-backed plugins have extra steps not covered here. Nothing here is legal or tax advice — the tax section flags where to consult your own accountant. Freemius SDK function names below match the current PHP SDK; check their docs for your exact version.

Phase A — Pre-migration audit (before you touch any code)

1. Inventory exactly what you are selling. Write down the plugin's slug, current version, PHP and WordPress minimums, every premium feature, every add-on, and any bundled libraries. You cannot fence what you have not listed. Note which features are free-tier-acceptable and which must sit behind a license — this list drives Phase E.
2. Pull an honest active-install reality check. From your CodeCanyon dashboard, note total sales, refunds, and the last-90-day sales pace. Then be clear-eyed: total sales is not your reachable audience. CodeCanyon buyers are one-time lifetime purchases and Envato never gave you their emails. The people you can actually re-license are the slice whose install is still live and who take one more update. Estimate that slice low, not high — it sets realistic expectations for the whole migration.
3. Choose your destination and merchant-of-record model. Two honest options. Freemius acts as merchant of record (they handle VAT/sales-tax remittance, chargebacks, EU invoicing) for an all-in cost of roughly 10.5% — about 4.7% platform + 2.3% WordPress-distribution fee + roughly 3.5% payment gateway. Self-hosted (Easy Digital Downloads or WooCommerce + Software Licensing + direct Stripe) runs about 3–5% in payment fees but makes you the merchant of record — you owe the VAT/tax compliance yourself. Rule of thumb: under a few hundred a month, or if EU VAT terrifies you, Freemius earns its cut; higher volume with an accountant already in place, self-hosted keeps more. Decide now, because it changes Phases C and J.
4. Snapshot your current licensing and update mechanism. Document exactly how the plugin authenticates today: the Envato purchase-code prompt, the Envato Market updater (or Envato WordPress Toolkit, or an EDD Software Licensing client you already bolted on), and every place the code calls Envato's API or checks a purchase code. This is your removal map for Phase F — you cannot cleanly swap the updater until you know every hook it touches.

Phase B — Export your license and sale data

5. Generate a scoped, read-only Envato API token. In your own Envato account, create a personal token with only the read scopes you need: "View your items' sales history" and "View and search Envato sites." Do not grant write scopes. You never need your Envato password for any of this, and no third party ever should ask for it.
6. Export your sales and purchase-code data. Use the Envato API (/v3/market/author/sales and the purchase-code verification endpoint) to pull your sales records into a CSV/JSON you control. You will need this to (a) validate purchase codes at redemption time and (b) understand your buyer base. Store it encrypted; it is personal data under GDPR and you are the controller.
7. Back up the plugin and tag a known-good release. Commit the current shipping code, tag it (e.g. v-preexit), and archive the exact zip currently live on CodeCanyon. Every change from here is reversible against this tag. Archive, never delete — if a buyer reports a regression later, you want the pre-migration build to compare against.

Phase C — Stand up the new store

8. Create the product on your new platform. On Freemius: create the plugin product, set the slug to match your plugin, and note your product ID, public key, and secret key (the secret stays server-side only). On self-hosted EDD/Woo: install Easy Digital Downloads (or WooCommerce) plus its Software Licensing extension and create the download.
9. Run the free license-data import and define your plans. Freemius imports existing license data for free — use it; do not hand-roll this. Define your plan structure: a free tier (if any), paid plan(s), pricing, and whether licenses are annual or lifetime. Match your CodeCanyon pricing at launch so buyers see continuity, then adjust later.
10. Configure taxes, VAT, and the merchant-of-record settings. If you chose Freemius, confirm they are set as merchant of record and that EU VAT / US sales tax handling is enabled — this is most of why you would pay their fee. If self-hosted, this is where you wire your own tax logic (Stripe Tax, or a VAT plugin) and register for VAT MOSS/OSS if the EU thresholds apply to you. Get this right before your first sale, not after.
11. Set up checkout, receipts, and a written refund policy. Configure the checkout, the automated receipt/invoice template (buyers will need proper VAT invoices you never had to issue on CodeCanyon), and publish a plain refund policy. Test one real end-to-end purchase in the platform's test/sandbox mode before going near buyers.

Phase D — Vendor the Freemius SDK and wire fs_dynamic_init()

12. Vendor the Freemius WordPress SDK into your plugin. Download the current PHP SDK and drop it into your plugin, conventionally at /freemius/. Vendor it (commit it into your codebase) rather than depending on it being installed separately — your plugin must be self-contained on a buyer's site.
13. Wire fs_dynamic_init() at the top of your main plugin file. This is the core hook that registers your plugin with the SDK. A minimal, honest starting point: if ( ! function_exists( 'my_plugin_fs' ) ) { function my_plugin_fs() { global $my_plugin_fs; if ( ! isset( $my_plugin_fs ) ) { require_once dirname(__FILE__) . '/freemius/start.php'; $my_plugin_fs = fs_dynamic_init( array( 'id' => '33401', // your product ID 'slug' => 'my-plugin', 'type' => 'plugin', 'public_key' => 'pk_xxxxxxxxxxxxxxxxxxxxx', 'is_premium' => true, 'has_paid_plans' => true, 'menu' => array( 'slug' => 'my-plugin-settings' ), ) ); } return $my_plugin_fs; } my_plugin_fs(); do_action( 'my_plugin_fs_loaded' ); } Replace the id, slug, and public_key with your real values from Step 8.
14. Add the SDK require guard and the helper accessor. The my_plugin_fs() accessor above is how the rest of your code asks about license state. Make sure it loads before any premium code path runs, and that a fresh activation with no license does not fatal — the SDK's opt-in screen should appear instead.
15. Set the free/premium build flags correctly. Decide whether you ship a single codebase with is_premium => true or use Freemius's free/premium two-build model. For a plugin that was paid-only on CodeCanyon, a single premium build with has_paid_plans => true is the simplest honest path. Confirm the SDK's deployment/build step produces the zip you will actually distribute.
16. Test the full activation lifecycle in a local sandbox. On a throwaway WordPress install, verify: fresh activation shows the opt-in, connecting a test license unlocks premium, deactivation and reactivation behave, and the Freemius "Account" tab renders. Do not skip this on a live buyer site — that is what the sandbox is for.

Phase E — Fence the premium features

17. Gate every premium code path behind a license check. Wrap paid functionality in my_plugin_fs()->can_use_premium_code() (or is_plan() for plan-specific gating). For code that must never even load without a license, use the SDK's __premium_only file/function naming convention so the free build physically excludes it. Work through the premium-feature list you made in Step 1 — each item gets a gate.
18. Degrade gracefully for expired or unlicensed users. An expired license must never cause a fatal error or a white screen. Premium features should quietly switch off with a clear, non-nagging upgrade prompt, and the plugin's free/core behaviour must keep working. Test with: no license, an expired license, and a valid license. This is the difference between a professional migration and an angry support queue.

Phase F — Replace the Envato/EDD updater

19. Remove the old update mechanism. Using your removal map from Step 4, strip out the Envato Market updater, the Envato WordPress Toolkit hooks, any purchase-code entry prompts, and any EDD Software Licensing update client. Leaving two updaters wired at once causes update conflicts and duplicate admin notices.
20. Let the Freemius SDK own updates, then verify delivery. With the old updater gone, the SDK handles update checks and delivery from your new store automatically for licensed users. Verify it end-to-end in the sandbox: publish a new version on the store, confirm a licensed test site sees the update and installs it cleanly. An update path you have not watch work is an update path you cannot trust.

Phase G — The purchase-code redemption bridge

21. Build the redemption flow: Envato purchase code in, new license out. This is the piece DIYers most often underestimate, so here is the full shape. A buyer pastes their Envato purchase code (and an email) on your new store; your server validates that code against the Envato API (Step 5's token), and — if it is valid and has not been redeemed before — issues a fresh Freemius license for the matching plan. It must be: server-side (never trust the client), one-time (dedupe every redeemed code so one purchase cannot mint infinite licenses), rate-limited (a public code-validation endpoint is an abuse target), and logged (you will need an audit trail when a buyer disputes). Freemius ships a bridge form, but nobody operates the validation, dedup, and license-issuance logic for you — that is the real engineering in a migration, and honestly the main thing the paid service exists to do.

Phase H — Final CodeCanyon update and item description

22. Ship the final CodeCanyon update carrying the migration notice. Push one last version to CodeCanyon that adds an in-plugin admin notice telling existing buyers how to redeem their purchase code on your new store. This is your single best channel to reach the live-install slice — Envato never gave you their emails, but this update reaches every buyer who still installs updates. Keep it factual and policy-safe; the update goes through Envato's normal review and that decision is not in your hands.
23. Update the item description and support policy honestly. Revise the CodeCanyon listing to reflect where support and updates now live. Do not disparage Envato and do not over-promise; state plainly that continued updates come via the new store and how redemption works. Note: Envato may or may not approve description changes that point off-platform — write it to survive review, and have a fallback if it does not.

Phase I — Buyer communication

24. Draft the migration email sequence. Email only addresses you already lawfully hold (support tickets, opt-ins, prior direct sales) — not scraped or Envato-side data you were never given. Send under your own sender identity. A simple three-touch sequence works: announce the move and why, explain redemption step by step, and a final reminder before any old-channel support winds down. Keep it calm and specific; no fake deadlines, no manufactured urgency.
25. Add the in-plugin admin notice pointing to redemption. Beyond the one-time update banner, a dismissible admin notice inside the plugin gives buyers a persistent, honest path to redeem. Make it dismissible (respect the user), link straight to your redemption page, and remove it once a site has redeemed.

Phase J — Tax and receipt cleanup

26. Reconcile tax and receipts across the switch. On CodeCanyon, Envato was the merchant of record — they issued invoices and remitted tax, and you just received payouts. After the move, either Freemius takes that role (if you chose them) or you do (self-hosted). Update your bookkeeping accordingly: new invoice/receipt templates with your VAT details, correct tax treatment of sales in each jurisdiction, and — if self-hosted — check whether EU VAT OSS registration now applies to you. This is the step people forget until their accountant asks. If in doubt, ask your accountant before your first non-Envato sale, not at year end.

Phase K — Post-move support

27. Set up support and monitoring for the first weeks after go-live. Watch three things: redemption failures (a valid code that would not issue a license), update-delivery errors, and refund/dispute requests. Have a written path for each. Budget for roughly a month of elevated support as buyers trickle through redemption — most migration-caused defects surface in the first 30 days, which is exactly why a bounded post-move support window is the sane commitment to make (to yourself, or to your buyers).