Migrate WebCalendar 1.9 to WordPress
Two different programs share the name WebCalendar. WebCalendar 1.9 is the standalone PHP and MySQL application you install on your own server. WebCalendar for WordPress is the plugin. They are separate codebases from the same developer, and this page is the supported path from the first to the second.
The migration is free, it runs from your WordPress dashboard or WP-CLI, and every run can be undone. If you only came here looking for the standalone app, that is answered first — below.
First: Which WebCalendar Are You Looking For?
Most people who search for a WebCalendar version number want the standalone app, not the plugin. Rather than send you in circles, here is where each one actually lives.
| If you searched for… | You want | Where it lives |
|---|---|---|
| webcalendar 1.9.x, 1.3.0, 1.2.x, 0.9.x | The standalone open-source PHP/MySQL app. Latest release: v1.9.23. | k5n.us/webcalendar · source on GitHub |
| wordpress calendar plugin | WebCalendar for WordPress — the plugin. Requires PHP 8.1+ and WordPress 6.6+. | Free on WordPress.org · product page |
| webcalendar to wordpress | The migration path — moving an existing 1.9 install into WordPress. | You are on the right page. Skip to the steps. |
The plugin is not a port of the standalone app and does not reuse its code. What it does have is a purpose-built importer that reads a 1.9 database and rebuilds it inside WordPress.
Should You Migrate at All?
Not everyone should. The standalone app still works, and moving a calendar you depend on is not a decision to make on enthusiasm. Here is the honest split.
Migrate if…
You already run WordPress and want one login, one backup and one set of user accounts instead of two. Or you want a calendar that is actively maintained against current PHP and WordPress, with recurring events, iCal in both directions, a REST API and an MCP server for AI assistants — all in the free edition.
Stay put if…
You do not run a WordPress site, or you have customized the standalone app’s PHP and depend on those changes. The importer moves your data, not your patches. If you are unsure whether a legacy feature has an equivalent, run a dry run against a staging site before committing.
Nothing forces the choice today. The importer is idempotent and reversible, so a trial migration on a staging site costs you an afternoon and tells you the answer for certain.
Before You Start: Fix Your Site Time Zone
This is the one step that cannot be repaired afterwards, so do it first.
Open Settings → General in WordPress and check the Timezone field. It must be a city — America/New_York, Europe/London — and not a fixed UTC offset like UTC-5. A fixed offset cannot observe daylight saving time, so imported events land an hour off for part of the year.
Correcting the setting later does not repair events that were already imported. WebCalendar for WordPress warns you about this on the Import screen, on Remote Calendars, on Settings, and as a Site Health test — but the cheapest time to get it right is before the first run.
Legacy WebCalendar stores event times in GMT. The importer converts them to your site time zone on the way in, which is exactly why that setting has to be correct before you begin.
How the Migration Works
Four steps, all from the WordPress admin. Budget an hour for a first pass on a staging site.
| Step | What you do | Notes |
|---|---|---|
| 1. Export | In the standalone app, use the Export for WordPress page. A plain mysqldump of the webcal_* tables works just as well. | Either format is accepted. The file is parsed, never executed. |
| 2. Upload | In WordPress, go to Import → WebCalendar 1.9 and select the file. | Large export? See the three routes below — you do not have to touch PHP limits. |
| 3. Map users | Match each legacy user to an existing WordPress account, or have new accounts created for them. | New accounts receive password-setup emails. Legacy password hashes are never imported. |
| 4. Choose and run | Select what to bring over, then run the import. | Re-running the same file changes nothing, and the whole run can be undone from the same screen. |
Afterwards: Recover Your Custom Fields
If your 1.9 calendar used custom fields, their values come across with your events — but the field definitions do not. Legacy WebCalendar kept those in a PHP file the importer cannot read, so at first the values are there without any labels attached to them.
Go to Calendar → Custom Fields and click Find fields in existing data. The plugin reconstructs the definitions from the imported values themselves. Labels and drop-down choices are educated guesses, so review them before saving — but it turns an afternoon of retyping into a single click.
What the Importer Guarantees
These are properties of the importer itself, not advice — you get them whether or not you read this page.
| Guarantee | What it means in practice |
|---|---|
| Reversible | Every migration run can be undone from the same screen it was started on. |
| Idempotent | Importing the same file twice is a no-op. A half-finished attempt can simply be re-run. |
| Clean rollback on failure | A run that fails partway removes the WordPress accounts it created for that run, so retries do not leave debris. |
| Never executes your dump | The .sql file is parsed as data. Nothing in it runs against your database. |
| Skips deleted events | Events deleted in the legacy calendar stay deleted rather than reappearing in WordPress. |
| Sanitizes recurrence | Recurrence data is sanitized on the way in, and an unparseable rule can no longer break the events feed. |
Large Installs: Three Routes Past the Upload Limit
A calendar with years of history can produce a dump larger than PHP will accept over HTTP. On shared hosting you often cannot raise upload_max_filesize or post_max_size at all — so of the three routes below, two skip the HTTP upload path entirely and never touch those limits.
| Route | How | Use it when |
|---|---|---|
| Browser upload | Import → WebCalendar 1.9, pick the file. | Your export fits inside the PHP limits. If it does not, the error names your current upload_max_filesize and post_max_size and how to raise them. |
| File already on the server | SFTP the .sql into wp-content/uploads, then choose Import a file already on the server. | You cannot change PHP limits. This bypasses the HTTP upload path entirely. The path is validated to stay inside the uploads folder, and the file is deleted after a successful import. |
| WP-CLI | wp webcal migrate legacy <file.sql> | The largest installs, or any time you want to rehearse. No HTTP upload limit at all. Takes --map, --create-missing, --include and --dry-run. |
Recommended: run wp webcal migrate legacy <file.sql> --dry-run first, whatever route you end up using. It reports what would happen without writing anything, which turns a migration into a rehearsal.
The bare wp webcal migrate <file.sql> form used before 1.1.7 still works and still means the same thing.
What You Get on the Other Side
Everything below is in the free edition on WordPress.org. None of it is a migration-only bonus or a trial.
Recurring events, free
Full RFC 5545 recurrence, including editing a single occurrence separately from the series. Every other major WordPress calendar plugin charges for this.
Calendars that talk to things
iCal import and export, subscribed remote calendars that re-sync, CSV in both directions, a REST API, Gutenberg blocks, and a 100+ country holiday library.
A calendar your AI can manage
A built-in MCP server, free in every edition, so Claude, ChatGPT or Cursor can read and write real events. No other major calendar plugin ships one.
Migration FAQ
Is WebCalendar for WordPress the same program as WebCalendar 1.9?
No. They are separate codebases from the same developer. WebCalendar 1.9 is the standalone PHP and MySQL application you install on your own server, and its latest release is v1.9.23. WebCalendar for WordPress is a WordPress plugin, first released in March 2026, that requires PHP 8.1+ and WordPress 6.6+. The plugin is not a port of the standalone app, but it ships an importer that reads a 1.9 database directly.
Where do I download the standalone WebCalendar app?
From k5n.us/webcalendar or from the source repository at github.com/craigk5n/webcalendar, where the current release is v1.9.23. Older releases in the 1.2.x, 1.3.0 and 0.9.x series are part of the same project history. Agenticdaisy.com publishes the WordPress plugin, not the standalone app.
Will my recurring events survive the migration?
Yes. Recurrence data is carried across and sanitized on the way in, and recurring events are part of the free edition rather than a paid add-on. An unparseable legacy rule is handled rather than allowed to break the events feed.
What happens to my legacy user accounts and passwords?
You map each legacy user to an existing WordPress account, or have the importer create new accounts for them, which receive password-setup emails. Legacy password hashes are never imported, so nobody carries an old password into WordPress.
Can I undo a migration if it goes wrong?
Yes. Every run can be undone from the same screen that started it. Importing the same file twice is also a no-op, so a partial attempt can simply be re-run, and a run that fails partway removes the WordPress accounts it created for that run.
My export is too big to upload. What now?
Two routes avoid the HTTP upload path entirely. You can SFTP the .sql file into wp-content/uploads and pick “Import a file already on the server,” which bypasses upload_max_filesize and post_max_size and deletes the file after a successful import. Or use the WP-CLI command wp webcal migrate legacy <file.sql>, which reads straight from disk and has no upload limit at all.
Can I test the migration before committing to it?
Yes, and you should. Run wp webcal migrate legacy <file.sql> --dry-run to see exactly what would be imported without writing anything. Doing that against a staging site is the cheapest way to find out whether the result is what you want.
Does the migration cost anything?
No. The WebCalendar 1.9 importer, the WP-CLI migrate command and everything it brings across are in the free edition on WordPress.org. If you are moving a large install across many sites and want help, email info@agenticdaisy.com.
Ready to Move Your Calendar?
Install the plugin, check your site time zone, and run a dry run against a staging site. If anything about your install looks unusual, ask before you migrate — the people who wrote the importer answer the email.
More detail: the product page, the full changelog, or the general FAQ.