Action Scheduler’s migration system moves scheduled actions from legacy WP Post-based storage to custom database tables for improved performance and scalability.

Why Migration Exists

Prior to Action Scheduler 3.0, all scheduled actions were stored as custom post types (scheduled-action) with logs stored as comments. This approach had limitations:

• Performance: WP Post queries don’t scale well with large action queues
• Database bloat: Thousands of posts/comments pollute core tables
• Query efficiency: Custom tables allow optimized indexes for action scheduling

Migration Flow

Site loads Action Scheduler 3.0+
    └── ActionScheduler_DataController::init()
            └── Check: is_migration_complete()?
                    ├── YES → Use DB store directly
                    └── NO → Controller::init()
                            ├── Use HybridStore (reads from both)
                            ├── Schedule migration via Scheduler
                            └── Runner processes batches
                                    └── When complete → mark_migration_complete()

Key Components

Completion Detection

Migration is tracked via the action_scheduler_migration_status option:

// Check if migration is complete
ActionScheduler_DataController::is_migration_complete();

// Mark migration complete (internal)
ActionScheduler_DataController::mark_migration_complete();

Hooks

HybridStore During Migration

While migration is in progress, ActionScheduler_HybridStore acts as a bridge:

• Reads: Queries both old (post) and new (DB) stores
• Writes: Always writes to new DB store
• Deletes: Removes from both stores

This ensures no actions are lost during the transition.

Admin Notice

During migration, a warning appears in the admin:

"Action Scheduler migration in progress. The list of scheduled actions may be incomplete."

"Action Scheduler migration in progress. The list of scheduled actions may be incomplete."