Why WordPress.org is Moving from HelpScout to Self-Hosted FreeScout
The WordPress.org Meta and Systems teams are transitioning the project’s help desk infrastructure from HelpScout to a self-hosted instance of FreeScout, located at freescout.wordpress.net. This decision was largely driven by a fundamental shift in HelpScout’s pricing model, which moved from contact-based billing to user-based subscription tiers. For an open-source enterprise managing tens of thousands of support conversations across decentralized contributor teams, user-based pricing scales poorly.
By migrating to an open-source, self-hosted FreeScout environment, WordPress.org achieves three distinct infrastructure goals:
- Long-Term Scalability: Eliminates per-user license fees across roughly 86 contributor and administrator accounts.
- Expanded Tooling Access: Allows broader community groups and contributor teams to utilize shared help desk tools without administrative overhead.
- Deep System Customization: Enables custom code integration tailored specifically to internal workflows, such as those required by the Plugins team and the WordPress.org directory codebase.
Technical Infrastructure and WordPress.org SSO Integration
One of the primary core enhancements of the new setup is the consolidation of user identity management. Previously, HelpScout required distinct, unlinked accounts for support agents and team members. The new FreeScout deployment fully integrates with WordPress.org Single Sign-On (SSO), mirroring the access architecture used by the official WordPress.org Slack network.
This SSO migration provides critical security and administrative controls:
- Automated Identity Provisioning: All 86 existing HelpScout account holders automatically receive access to
freescout.wordpress.netthrough their primary WordPress.org credentials without needing manual account registration. - Enforced Two-Factor Authentication (2FA): System access inherits central authentication policies, enforcing mandatory 2FA across all account profiles.
- Proxy Control for Administrators: Simplifies compliance and administrative auditing by facilitating mandatory Proxy access controls for system administrators.
- Account Data Synchronization: Syncs known profile information directly from WordPress.org user metadata.
Phased Execution: Structuring the Mailbox Rollout Strategy
Managing the migration across approximately 20 distinct mailboxes requires isolating simple email-only channels from heavily automated, API-driven workflows. Rather than executing a high-risk cutover, the Systems team designed a 5-phase schedule prioritized by risk profile, workflow complexity, and API dependencies.
The explicit objective of the rollout strategy is operational stability over speed. Phasing the deployment gives teams time to commission required FreeScout modules, audit incoming webhooks, and ensure custom integrations remain functional post-cutover.
Phases 1 and 2: Pilot Mailboxes and Low-Automation Services
The initial phases focus on baseline validation of the FreeScout deployment through low-volume or unautomated inboxes before handling mission-critical or sensitive workflows.
Phase 1 (Pilot Inboxes):
- Photos: 297 total conversations, averaging ~3 new tickets per week. Operates strictly via email with 1 basic workflow.
- Jobs: 439 total conversations. Operates strictly via email with 0 existing workflows.
Phase 2 (Small Inboxes with Minimal Automation):
- Hosting: Requires verifying mailbox ownership prior to cutover.
- WordPress Meetup Support & Memorials: Standard email support mailboxes.
- Five for the Future: Requires initial triage of pending open conversations.
- WPF Scholarships: Involves tracing the technical origin of occasional API-generated conversations.
- Openverse: 4 custom workflows.
- Themes: 8 custom workflows.
Phase 3: Handling Moderate Configurations, Custom Fields, and Saved Replies
Phase 3 introduces mailboxes that rely on tailored response templates, structured metadata, and moderate workflow rule sets. Successfully migrating these inboxes requires syncing FreeScout’s custom field modules and importing legacy saved replies.
| Mailbox Name | Custom Fields | Workflows | Saved Replies / Dependencies |
|---|---|---|---|
| WP Project Reports | 4 | 0 | 0 |
| Learn WordPress | 2 | 7 | 28 |
| WordPress Trademarks | 0 | 0 | 27 |
| Mercantile | 0 | 0 | Requires open conversation triage prior to move |
Phase 4: Navigating High-Traffic, Sensitive Data, and API Dependencies
Phase 4 encompasses high-volume, highly automated, and security-sensitive channels. These inboxes rely heavily on custom web intake endpoints, programmatic API ingestion, and complex routing logic.
- WPF Education: Involves replacing both web intake forms and external API submission handlers.
- WordPress.org Security: Contains sensitive operational and vulnerability data; requires strict access verification.
- Password Resets: Relies on 28 automated routing and processing workflows.
- Data Mailbox: High-volume traffic pipeline managing 45 automated workflows.
- WordPress Community Team: The single largest mailbox in the infrastructure, comprising over 97,000 historical conversations, 70 distinct workflows, 304 saved replies, and an external API intake mechanism.
Phase 5: Deep Plugin Directory Integration and Customization
The final phase isolates the Plugins team inbox. This inbox is treated as a distinct migration milestone because the backend WordPress.org Plugin Directory core codebase is directly wired into HelpScout via programmatic endpoints and bespoke tooling.
Migrating Phase 5 requires refactoring the Directory plugin code to point toward FreeScout’s API endpoints, verifying webhook listeners, and testing developer communication loops. To protect plugin submission queues and security reviews, this step is scheduled last to prevent operational bottlenecks.
Rollout Timeline, Paid Module Provisioning, and Team Communication
Deployment scheduling depends on Systems team availability, module configuration speed, and successful testing of external API logic. The target execution schedule is structured as follows:
- Tuesday, October 6: Configure module synchronization and commission paid FreeScout modules required for custom fields, workflows, and integrations.
- Wednesday, October 7: Import legacy user accounts and recreate operational workflows inside FreeScout.
- Thursday, October 8: Begin active migration of Phase 1, Phase 2, and Phase 3 mailboxes (with execution extending into the following week as needed).
- Monday, October 12: Initiate migration of Phase 4 mailboxes (Security, Data, Community Team).
- Monday, October 19: Begin Phase 5 migration for the Plugins team inbox and core directory integrations.
To minimize friction across the ~20 mailboxes and 86 account holders, team leads will notify members via direct manual email notifications once their specific mailbox transition is complete. Contributor teams operating custom webhooks, web forms, or external API routines are encouraged to verify their system endpoints against the new FreeScout deployment environment.
Frequently asked questions
Why is WordPress.org migrating from HelpScout to FreeScout?
HelpScout shifted from a contact-based pricing model to a user-based pricing model. Migrating to a self-hosted FreeScout instance allows WordPress.org to lower long-term infrastructure costs across 86 accounts, expand tooling access to more community teams, and customize inboxes directly via custom PHP/WordPress directory code.
How will support team members log into the new FreeScout instance?
Access will be unified using standard WordPress.org Single Sign-On (SSO) at freescout.wordpress.net. This automatically provides access to existing account holders, enforces mandatory Two-Factor Authentication (2FA), and enables required Proxy controls for Administrator accounts.
Which mailbox is the most complex to migrate during this process?
The WordPress Community Team mailbox is the largest by volume (97,000 conversations, 70 workflows, 304 saved replies, external API intake), while the Plugins team inbox is technically the most complex due to direct code dependencies inside the WordPress.org Plugin Directory codebase.
When is the migration scheduled to complete?
Initial module configuration begins October 6, with Phase 1–3 migrations starting October 8, Phase 4 starting October 12, and the final Phase 5 (Plugins team) beginning October 19.
Primary reference: Review the original announcement for exact release details. This article is an independent explanation and does not reproduce the source text.