The important distinction
Keeping a project published and keeping paid features are two different things.
If you want an already-published project to remain accessible after the paid plan expires, open its publishing settings before expiration and enable Keep the project published when the plan changes. The published project then moves to the trial plan and remains online. If this option is not enabled, the project is unpublished when the plan changes.
Paid-plan-only features do not remain available merely because the project stays published. Download important response data before expiration and do not treat the online dashboard as your only backup.
Four changes to check
| Concern | After expiration | Action before expiration |
|---|---|---|
| Can the project URL remain open? | An already-published project stays online under the trial plan only when continuous publishing is enabled; otherwise it is unpublished | Review publishing settings for every required project |
| Are paid features retained? | No; the project follows the feature limits of the resulting plan | Review every paid block or integration the project depends on |
| Is response data a permanent backup? | Do not assume indefinite online retention or access | Export and securely store important data |
| Does a billing problem change immediately? | Billing and plan state follow the actual order status | Contact support with the account and order details when help is needed |
Decide from your current situation
- The project is published and must stay accessible: enable continuous publishing before the plan changes, then test the public URL afterward.
- The project relies on paid functionality: document which feature is required and renew or change the implementation before the feature becomes unavailable.
- The responses matter for operations or research: export them now and verify that the downloaded file opens correctly.
- The project is no longer needed: archive your data and allow it to be unpublished rather than leaving an unmaintained campaign live.
Steps before the plan expires
1. Download important data
Export the response records required by your team. Open the downloaded file, verify its encoding and columns, and save it in the approved team location. If several projects are involved, repeat this for each project.
2. Enable continuous publishing during plan changes
Open the project's publishing settings and enable Keep the project published when the plan changes. Save the setting and confirm it remains enabled after reloading the editor.
3. Check the participant experience
Open the published link in a signed-out or private window. Complete the main path and verify that no paid-only block is required for the experience to finish.
Pre-expiration checklist
- Important response data has been exported and opened successfully.
- Every project that must remain online is currently published.
- Continuous publishing is enabled and saved on each of those projects.
- Paid-only features and integrations have been inventoried.
- A participant can still complete the intended path under the future plan limits.
- The team knows who will handle billing or renewal questions.
FAQ
Does continuous publishing preserve paid features? No. It controls publication continuity; feature access follows the active plan.
Can I enable the option after the project has already been unpublished? The safe workflow is to set it before expiration. If the plan has already changed, review the current project and plan state before republishing.
Is downloading the response table enough? Open the file and verify it. A download that cannot be read by the team is not a usable backup.
What should I send when asking for billing help? Include the account email, relevant project or order information, and a clear description of the expected and current plan state. Never send passwords or full payment-card details.
Review the current plan options early enough to test any change before the expiration date.
