On 1 February 2025, BookingPress was removed from the wordpress.org plugin repository following a guideline violation. It continues to be sold and supported directly by its vendor, and sites running it did not stop working. But the removal changed something real about how the plugin reaches your site, and it is a reasonable prompt to reassess.

This article sets out what a repository closure actually means, gives an honest risk assessment for sites already running it, compares the alternatives if you decide to move, and covers migration without losing booking history. It also draws the more general lesson, which is worth more than the specific case.

Verified August 2026. Prices are vendor list prices; confirm before purchasing.

---

What a repository closure means, and what it does not

Start with what did not happen, because the alarm in some coverage of this exceeded the facts.

Your site did not break. A plugin removed from the directory keeps running exactly as before. Nothing is deactivated, no data is touched, and bookings continue.

The vendor did not disappear. BookingPress is still sold, still developed and still supported through its own website. Direct distribution is a normal and legitimate model that many well-regarded commercial plugins use exclusively.

A closure is not a security finding. Removals happen for a range of guideline reasons, many of them about listing conduct rather than code quality, and treating a closure as evidence of a vulnerability is a misreading.

What genuinely changed is the update path. Automatic updates through wp-admin, the directory’s changelog and version history, the public support forum and the review record all flow through the repository. Without it, updates arrive through the vendor’s own licensing system, and if that lapses, so does your update channel. For a managed site that is a small operational change to absorb. For an agency maintaining forty sites, it is a genuine process problem, because plugins outside the repository need their own tracking.

---

Risk assessment if you are already running it

Panic migration is usually a worse outcome than staying put. Work through these before deciding anything.

• Confirm your update channel works. Check that your licence is active and that the plugin can reach the vendor for updates. If updates are arriving, the practical risk is low.
• Export your booking data now. Do this regardless of what you decide. Appointments, customers, services and staff, exported to a file you keep. It is the mitigation for every scenario and takes ten minutes.
• Ask the vendor directly about roadmap. A vendor still shipping updates and answering support tickets is a vendor still in business. Silence over several months is the signal to act on, not a directory listing.
• Weigh migration cost honestly. Moving a live booking system means reconfiguring services, staff, availability and notifications, retraining whoever uses it, and accepting a period where something is misconfigured. That cost is real and it is not small.
• Consider the client-facing angle. If you are an agency, a client asking why their plugin is not in the directory is a conversation you will have repeatedly. That alone sometimes justifies moving.

The proportionate answer for most sites is: export your data, verify updates are arriving, and stay until you have another reason to move. Reassess if updates stop, if support goes quiet, or if you are rebuilding the site anyway.

---

The 6 alternatives compared

---

Comparison table

Option	Entry price	In the repository	Migration effort	Feature depth
Amelia	$149/yr	Yes	Moderate	High
FluentBooking	$63/yr	Yes	Low	Moderate
LatePoint	$79/yr	Largely direct	Moderate	Moderate
Simply Schedule Appointments	Free	Yes	Low	Moderate
Bookly	Low base	Free version	Moderate	Add-on dependent
Stay put	Current licence	No	None	Unchanged

---

Migrating without losing history

There is no import tool between booking plugins. Every migration is manual, and the order you do things in decides whether it is tedious or painful.

Export everything first. Appointments, customers, services, staff and settings, as CSV where offered and as a database backup regardless. Keep it outside the site. This is your only insurance and it costs ten minutes.

Build the new configuration alongside the old one, on a staging copy if you have one. Services, staff, availability, notification templates and payment settings, all reproduced before anything is switched. Both plugins can be installed at once; only one should have a booking page published.

Choose a cutover date past your furthest future booking, or accept that you will re-enter the remainder by hand. Most practices have a natural quiet week. Use it.

Keep the old plugin installed but deactivated for a few months. Its data stays in the database, so a question about a booking from March is answerable. Delete it only once you are certain, since deleting typically drops the tables.

Test the full cycle before announcing anything. Book, receive the confirmation, check the calendar entry, cancel, confirm the slot reopens, and verify a payment reaches your account. Then repeat it for each staff member, because per-person connections are where migrations break.

---

Frequently asked questions

Did BookingPress stop working after the removal?

No. Sites running it continued normally, and the plugin is still sold and supported directly by its vendor. What changed is the update and support channel.

Does a repository removal mean the plugin is insecure?

Not by itself. Removals happen for a range of guideline reasons, many unrelated to code quality, so treat a closure as a prompt to check rather than as a finding.

Should I migrate immediately?

Usually not. Export your data, confirm updates are arriving, and move when you have another reason, such as a site rebuild or support going quiet.

Can I import my bookings into a new plugin?

No tool exists for this. Plan a manual rebuild, keep the old plugin deactivated for reference, and pick a cutover date past your furthest future booking.

Is repository presence a good longevity signal?

It is one signal among several, and a weak one on its own. Several excellent commercial plugins are sold only direct. Active development and responsive support matter more.

Which alternative is the easiest move?

Amelia if you need equivalent depth, since the concepts map directly. FluentBooking at $63 if the migration is a chance to simplify what you actually use.

---

The verdict

Do not migrate in a hurry. Export your booking data today, confirm updates are still arriving from the vendor, and set a reminder to reassess in six months. That converts an unexamined dependency into a monitored one, which is the real improvement available.

If you do move and need the same depth: Amelia, whose services, employees, locations and packages map onto what you already configured.

If the move is a chance to simplify: FluentBooking at $63, or Simply Schedule Appointments for a client site somebody else will maintain.

The general lesson outlasts the specific case. Every commercial plugin is a dependency on a company. Keep exports, know where your updates come from, and judge vendors on active development and responsive support rather than on a directory listing.