We have migrated eleven WordPress installations to JekCMS over the past year. The largest had 3,247 posts, 18 active plugins, and a custom post type structure that did not map cleanly to JekCMS's data model. This is an honest account of where automation works and where it does not.
Standard WordPress data — posts, pages, categories, tags, authors, and featured images — migrates cleanly. The migration script reads directly from the WordPress database using the configured table prefix and writes to the JekCMS schema in a single transaction. Both databases can run on the same server or different ones; the script uses separate PDO connections. Average migration time for 3,000 posts is 4–6 minutes.
Custom Post Types: The Main Complication
Custom post types are the main complication. JekCMS has a single post type with a flexible meta key-value system; WordPress's custom post types correspond to entirely different editorial workflows. For each CPT, you need to decide whether it becomes a JekCMS post with specific meta keys, a custom database table, or a set of JekCMS categories. The decision depends on whether the CPT content needs to appear in the main post feed or exists as a standalone section.
Mapping ACF Fields
ACF fields require explicit mapping in a configuration file. Create a field_map.php in the migration tools directory that maps ACF field names to JekCMS meta keys: 'acf_subtitle' => 'post_subtitle'. Boolean ACF fields become 0/1 integer values in JekCMS post meta. Repeater fields are JSON-encoded as a single meta value — build a custom query helper if your templates need to iterate over them.
Post-Migration URL Audit
After migration, run parallel crawls of both sites using Screaming Frog. Compare status codes and redirect chains. Every WordPress URL that returns 404 in JekCMS needs a redirect entry. JekCMS's config/redirects.php file accepts an array of source → destination pairs and supports regex patterns for bulk redirects like ^/\?p=(\d+)$ => /posts/$1.