Elementor: no built-in "deactivate but retain content" option — open feature request since 2018
Claim: Elementor has no built-in mechanism to deactivate and retain content as standard HTML/WordPress markup. This is tracked as an open feature request on GitHub: elementor/elementor issue #5667. Visual Composer/WPBakery and similar page builders write content to non-standard database tables or shortcodes that become orphan content on deactivation.
Sources: GitHub elementor/elementor issue #5667; Nelio Software analysis; WordPress Help Blog migration guides.
Confidence: Industry-consensus.
Implication: Elementor lock-in is structural rather than malicious — the builder's data model is fundamentally different from WordPress's native post_content. Practical exit requires either (1) a content rebuild, (2) commercial migration tools (Nelio, etc.), or (3) staying on Elementor. Related: Divi 4 stored content as proprietary et_pb_* shortcodes — orphan text on theme deactivation (Divi 5 fixes this), ACF custom fields don't survive WordPress's native XML export — image IDs + serialized arrays break.
Referenced by (4)
- reference ACF custom fields don't survive WordPress's native XML export — image IDs + serialized arrays break relates-to
- reference Research brief: Owning your stack — why agency-managed platforms cost more than they save (piece 4 of 15) relates-to
- reference GeneratePress official: "You cannot convert Elementor's code to the code required by the Block Editor" relates-to
- reference Content extraction decision tree — WP REST API default, WXR XML fallback, direct DB only for hidden postmeta relates-to