Does Switching WordPress Editors Affect Your Content?

Switching WordPress editors can affect how your content is edited, structured and sometimes saved, but simply changing from the Block Editor to the Classic Editor does not automatically delete or rewrite all of your existing content.

The important distinction is between:

changing the editing interface

and:

changing the stored content structure

Those are related, but they are not the same operation.

A WordPress post created in the Classic Editor may contain ordinary HTML stored in post_content. A post created in the Block Editor can also be stored in post_content, but WordPress adds block-delimiting comments and block attributes so the editor can reconstruct the individual blocks later.

That means switching editors can be harmless for simple content while becoming much more complicated for pages containing complex blocks, custom block markup, page-builder content, shortcodes or editor-specific formatting.

This guide explains what actually happens when you switch between the WordPress Block Editor and Classic Editor, how WordPress stores each type of content, what the Classic block does, when conversion changes your content, what can break, how themes and plugins affect the process and how to test an editor migration safely.

What does “switching WordPress editors” mean?

There are several different changes that people describe as switching editors.

You might be:

• opening an old Classic Editor post in the Block Editor;
• switching a Block Editor post back to the Classic Editor;
• installing the official Classic Editor plugin;
• disabling Gutenberg for selected post types;
• converting classic content into individual blocks;
• moving from a page builder to the native Block Editor;
• moving from the Block Editor to another visual builder.

These operations do not all have the same effect.

The editor and the content format are separate concepts

The editor is the interface you use to modify the post.

The content format is what WordPress ultimately stores.

A useful mental model is:

Editor
↓
lets you modify content
↓
content is saved
↓
post_content in database

The editing interface can change while the underlying database field remains the same.

Where does WordPress store post content?

Normal WordPress post and page content is stored primarily in the:

post_content

column of the posts table.

The Block Editor does not normally maintain an entirely separate duplicate copy of the article somewhere else simply because blocks are involved.

The official WordPress Block Editor data-format documentation explains that block content is serialized into post_content.

Classic Editor content is largely ordinary HTML

A simple Classic Editor post might be stored approximately like this:

<p>Welcome to our website.</p>

<h2>Our services</h2>

<p>We provide web development and design.</p>

The editor interprets that HTML and presents it through the classic TinyMCE editing interface.

Block Editor content includes block delimiters

A similar Block Editor post may be stored like this:

<!-- wp:paragraph -->
<p>Welcome to our website.</p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2>Our services</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>We provide web development and design.</p>
<!-- /wp:paragraph -->

The visible HTML remains understandable.

But the comments tell the Block Editor:

this HTML belongs to a Paragraph block

this HTML belongs to a Heading block

this HTML belongs to another Paragraph block

Block comments are part of the editor’s serialization format

The official Block Editor architecture documentation explains that WordPress serializes blocks into HTML and uses HTML comments as explicit block delimiters.

For example:

<!-- wp:image -->
<figure class="wp-block-image">
    ...
</figure>
<!-- /wp:image -->

The browser normally does not visibly display those comments on the frontend.

They exist so WordPress can reconstruct the block structure when the post is edited again.

So does switching editors delete those block comments?

Not merely because you installed or activated another editor.

Simply changing which editor WordPress opens does not inherently mean:

find every post
↓
rewrite post_content
↓
remove every block marker

The important changes occur when content is actually opened, modified, converted or saved through an editor that handles the stored markup differently.

Opening Classic Editor content in the Block Editor

When the Block Editor encounters traditional content that does not already contain normal block serialization, WordPress can preserve it inside a Classic block.

The official Classic block documentation describes the Classic block as an editing experience similar to the traditional Classic Editor inside the Block Editor.

The workflow can therefore be:

old classic post
↓
open in Block Editor
↓
content preserved
inside Classic block

The Classic block acts as a compatibility bridge

Instead of immediately converting every paragraph, image and heading into independent blocks, WordPress can keep the legacy content together.

Conceptually:

Classic content

<h2>Title</h2>
<p>Paragraph</p>
<img ...>

↓
Block Editor

Classic block
└── existing classic content

This reduces the need for an immediate structural conversion.

You can convert a Classic block into individual blocks

The Classic block includes a:

Convert to blocks

option.

The WordPress documentation confirms that selecting it converts compatible content into block structures.

For example:

Classic block
│
├── heading
├── paragraph
├── image
└── list

↓ Convert to blocks

Heading block
Paragraph block
Image block
List block

Conversion is more significant than simply switching editors

This distinction deserves emphasis.

Opening a classic post in the Block Editor:

does not necessarily mean
full structural conversion

Clicking:

Convert to blocks

can rewrite the content into explicit block serialization.

That is an actual content-format change.

Simple content usually converts well

Basic content such as:

• paragraphs;
• headings;
• lists;
• quotes;
• images;
• basic links;

is generally straightforward for the Block Editor to interpret.

A simple article consisting mostly of:

heading
paragraph
paragraph
image
heading
list

usually presents much less migration risk than a heavily customized landing page.

Complex HTML deserves more caution

Classic content can contain:

• custom HTML;
• inline styles;
• custom classes;
• shortcodes;
• plugin-generated markup;
• tables;
• embedded scripts;
• layout wrappers;
• legacy page-builder structures.

Not all of that maps neatly to standard WordPress blocks.

Invalid block content can appear after markup changes

Blocks have expected markup.

If their saved HTML no longer matches what the block expects, WordPress can show an:

Unexpected or invalid content

warning.

The official WordPress block-error documentation explains several possible causes, including manually changed HTML and plugin or theme conflicts.

Block validation is another reason not to edit serialized markup casually

A block may have been saved as:

<!-- wp:paragraph -->
<p class="has-text-align-center">
    Hello
</p>
<!-- /wp:paragraph -->

If another editor or custom process rewrites the markup in a way the block does not expect, the next Block Editor session may identify a mismatch.

WordPress provides recovery options

When block markup becomes invalid, WordPress may offer options such as:

• Attempt Block Recovery;
• Resolve;
• Convert to HTML;
• Convert to Classic Block.

The official Block API documentation explains how these recovery and conversion options interact with saved markup.

What happens when you switch from the Block Editor to Classic Editor?

This direction deserves more caution.

A Block Editor post can contain serialized block comments and block-specific markup that the Classic Editor was never designed to manage structurally.

The Classic Editor fundamentally sees content much more like:

HTML document

rather than:

tree of independent block objects

The frontend may continue looking correct

Because block serialization includes HTML, a block-based post can often continue rendering correctly even outside the Block Editor.

This compatibility is deliberate.

The WordPress Block Editor architecture documentation explains that block posts are stored in a format designed to remain readable by the wider WordPress ecosystem.

But editing the markup can damage block structure

The risk appears when the classic workflow changes content that the Block Editor expects to parse later.

Imagine this stored block:

<!-- wp:columns -->
<div class="wp-block-columns">

    <!-- wp:column -->
    <div class="wp-block-column">
        ...
    </div>
    <!-- /wp:column -->

</div>
<!-- /wp:columns -->

If another editor significantly restructures the HTML while leaving block comments behind, reopening the post in the Block Editor may cause validation problems.

Complex nested blocks increase the risk

Examples include:

• Columns;
• Groups;
• Cover blocks;
• Navigation structures;
• Query Loop blocks;
• custom plugin blocks;
• nested layout blocks.

These structures contain more relationships than a simple paragraph.

Dynamic blocks require another distinction

Some WordPress blocks do not store their complete rendered frontend HTML in the post.

Instead, they store block attributes and are rendered dynamically.

A conceptual example looks like:

<!-- wp:latest-posts
{"postsToShow":4} /-->

The frontend output is then generated dynamically.

The official Block Editor data-format documentation specifically describes this type of serialized dynamic block.

A classic editor cannot recreate every block editing interface

Even if the block marker remains stored correctly, the Classic Editor does not provide the block-specific controls associated with that component.

For example, a custom block may expose:

• Inspector controls;
• block toolbar settings;
• responsive options;
• color controls;
• inner blocks;
• dynamic configuration.

Those controls belong to the Block Editor environment.

This means preserving frontend output is not the same as preserving editability

A page can:

still look correct to visitors

while becoming:

much harder to edit safely

in another editor.

This is one of the most important distinctions when changing WordPress editing systems.

The official Classic Editor plugin can support editor switching

WordPress provides the official Classic Editor plugin.

Depending on its configuration, the plugin can allow users to choose the editor used for individual posts.

The plugin documentation also notes that posts can reopen using the editor most recently used for that content when editor switching is enabled.

That does not make every post equally safe in both editors

The existence of a:

Switch to Classic Editor

or:

Switch to Block Editor

link should not be interpreted as:

every content structure can be
round-tripped indefinitely
without consequences

The complexity of the saved content still matters.

Simple posts are usually the safest candidates

A traditional blog article containing:

• text;
• headings;
• images;
• lists;
• quotes;

is usually much easier to move between editing workflows than a custom-designed landing page.

Page-builder content is a different category entirely

Do not assume:

Classic Editor
vs.
Block Editor

is equivalent to:

Elementor
vs.
Block Editor

or:

Bricks
vs.
Classic Editor

Page builders can store layout information in:

• post meta;
• serialized arrays;
• JSON structures;
• shortcodes;
• custom database records;
• builder-specific markup.

Changing the editor does not automatically convert page-builder layouts

If a page was built with a third-party builder, opening the normal WordPress editor does not magically translate:

builder section
builder container
builder widget
builder styles

into:

Group block
Columns block
Heading block
Button block

Such a migration may require rebuilding the page.

Shortcodes may survive while their editing experience changes

Older WordPress sites often contain content such as:

[button url="/contact/"]

[products ids="12,14,18"]

Moving that content into another editor does not necessarily remove the shortcode.

But the editing experience may change.

The Block Editor can represent some shortcode-based content through a Shortcode block, while other plugins provide dedicated blocks.

Plugin availability still matters

An editor cannot independently render functionality provided by a missing plugin.

If a post contains:

[legacy_slider id="10"]

and the plugin providing that shortcode is removed, switching editors does not repair it.

The dependency is the plugin, not the editor.

Custom blocks create plugin dependencies too

A post may contain:

<!-- wp:plugin-name/special-card -->

If the plugin registering:

plugin-name/special-card

is removed, the Block Editor may no longer recognize the block normally.

Changing to the Classic Editor does not eliminate that dependency.

Reusable structures deserve careful testing

Block-based sites may also use:

• patterns;
• synced patterns;
• template parts;
• custom blocks;
• dynamic blocks.

These are different from ordinary standalone paragraph HTML.

For the wider architecture, see WordPress Full Site Editing and Block Widgets, Explained.

Switching editors is not the same as switching themes

Another frequent source of confusion is combining:

editor migration

with:

theme migration

Changing editors affects how content is edited.

Changing themes affects how the site presents and structures that content.

Those can happen together, but they solve different problems.

Your content can remain intact while its appearance changes

Imagine a post containing:

Heading block
Paragraph block
Image block

The content may remain completely unchanged in the database.

But changing the theme could alter:

• font sizes;
• spacing;
• content width;
• image styling;
• colors;
• block CSS.

That is presentation change, not necessarily content loss.

Editor CSS can make content appear different too

A post may look one way inside the Classic Editor and another way inside the Block Editor simply because the editing canvases load different styles.

That does not necessarily mean the saved content changed.

For the technical distinction, see WordPress Block Editor CSS Explained.

The Block Editor and frontend are not identical environments

Modern WordPress themes can provide editor-specific styling using mechanisms such as:

• theme.json;
• editor styles;
• block-specific stylesheets;
• block asset APIs.

The editing preview can therefore change after moving between editors while frontend content remains unchanged.

Do not judge migration success only from the editor

Always inspect:

editor
+
frontend

A migration can produce:

editor looks strange
but frontend correct

or:

editor looks correct
but frontend broken

Both environments matter.

What happens if you disable Gutenberg?

Disabling the Block Editor changes which editing interface WordPress provides for applicable content.

It does not automatically strip every block comment out of every existing post.

The existing content remains stored until something actually rewrites it.

If your project intentionally needs the classic workflow, TheOneWP Disable Gutenberg provides controls for disabling Gutenberg globally or for selected post types.

Disabling Gutenberg should be an architectural choice

Do not disable the Block Editor merely because:

Classic Editor feels familiar

without first checking whether the site depends on:

• custom blocks;
• block-based post layouts;
• block editor plugin controls;
• block-theme workflows;
• other Gutenberg-dependent functionality.

If you are still choosing between the editing models, see Block Editor vs. Classic Editor: Which Fits Your Site?.

What if you want the Classic Editor back?

If the site genuinely fits the traditional editing workflow, restore it deliberately rather than attempting to remove random Gutenberg assets until the editor stops appearing.

See How to Bring Back the Classic WordPress Editor.

Do not remove block frontend assets merely because you changed the editor

This distinction is particularly important.

You may disable the Block Editor for future editing while existing posts still contain blocks.

Those blocks may still require frontend CSS.

Therefore:

Block Editor disabled
≠
site contains no blocks

Existing content determines frontend requirements

Imagine:

500 existing posts
built with blocks

↓
Classic Editor enabled
for future editing

Those 500 posts do not suddenly become classic HTML-only content merely because the administration interface changed.

Removing block CSS could affect how they render.

The same warning applies to Remove Block Assets

TheOneWP Remove Block Assets can remove selected block-related frontend resources when they are genuinely unnecessary.

It should not be activated indiscriminately simply because editors now use a classic interface.

Check actual content before removing Gutenberg-related frontend assets

Search representative posts for serialized block comments such as:

<!-- wp:paragraph -->

<!-- wp:image -->

<!-- wp:columns -->

If the site contains block markup, review whether those blocks rely on frontend styles before disabling their assets.

Can you switch one post at a time?

Yes, depending on your editor configuration.

The official Classic Editor plugin can allow editor choice on individual posts.

This can be useful during gradual migrations.

For example:

Old article A
→ keep Classic Editor

Old article B
→ keep Classic Editor

New article C
→ Block Editor

Article D
→ convert and review

A gradual migration is often safer

Instead of converting hundreds of posts simultaneously:

all posts
↓
bulk conversion
↓
hope

a safer process may be:

select representative content
↓
convert
↓
review
↓
identify problems
↓
create migration rules
↓
continue gradually

Bulk conversion increases the need for backups

If a tool actually rewrites stored content into block markup across hundreds or thousands of posts, treat that as a database migration.

Before bulk conversion:

• create a full backup;
• test the restore process;
• use staging;
• sample different content types;
• record known problematic pages.

Revisions provide another safety layer

WordPress revisions can preserve previous versions of post content, depending on the site’s revision configuration.

They are useful when an editor save unexpectedly changes formatting.

However, revisions should not replace a proper pre-migration backup for a site-wide conversion.

Why revisions are not enough for a complete migration

An editor migration can also involve:

• plugin configuration;
• theme changes;
• post meta;
• custom blocks;
• CSS;
• JavaScript;
• templates.

A post revision does not necessarily restore all of those systems.

Test on staging first

For any significant editor migration, create a staging environment.

See WordPress Staging Site Best Practices.

Your staging copy should contain:

• the same theme;
• the same plugins;
• representative content;
• custom blocks;
• page-builder pages;
• shortcodes;
• realistic media.

Create a content inventory before switching

Classify existing content.

For example:

TYPE A
Simple Classic posts

TYPE B
Classic posts with shortcodes

TYPE C
Block Editor posts

TYPE D
Custom block posts

TYPE E
Page-builder pages

TYPE F
Custom HTML layouts

Each category may need a different migration strategy.

Do not use the same conversion rule for every post

A site-wide:

Convert everything to blocks

may work beautifully for:

simple blog articles

while causing problems for:

custom landing pages

or:

shortcode-heavy legacy content

Test representative posts from every content category

For each category, review:

• editor appearance;
• frontend appearance;
• HTML structure;
• responsive behavior;
• shortcodes;
• custom fields;
• forms;
• interactive components.

Compare before and after HTML

For important templates, inspect the rendered frontend markup before and after conversion.

You do not necessarily need byte-for-byte identical HTML.

You do need equivalent:

• content;
• semantics;
• links;
• media;
• interactive functionality;
• layout behavior.

Check heading structure

Conversion can expose old formatting where text merely looked like a heading but was actually:

<p>
    <strong>OUR SERVICES</strong>
</p>

rather than:

<h2>Our Services</h2>

An editor migration is a useful opportunity to correct structural content problems rather than preserving every historical formatting accident forever.

Check images carefully

Verify:

• image URLs;
• alternative text;
• captions;
• alignment;
• links;
• responsive sizing.

A conversion that preserves the visible image but loses its link or caption is not completely successful.

Check galleries

Legacy gallery shortcodes and modern Gallery blocks can use different structures.

Confirm:

• image order;
• column behavior;
• captions;
• lightbox functionality;
• responsive layout.

Check tables

Classic content can contain complex hand-written tables.

A Table block may not reproduce every unusual HTML table structure or custom attribute exactly.

Do not force conversion when preserving the existing HTML is safer.

Check custom HTML separately

The Block Editor provides a Custom HTML block for markup that should remain explicitly HTML-based.

Not every piece of HTML needs to be transformed into native blocks.

Sometimes:

preserve HTML
inside Custom HTML block

is safer than attempting an imperfect conversion.

Check shortcodes separately

Confirm that every important shortcode still:

• exists;
• renders;
• has its supporting plugin active;
• works in the target editing workflow.

Check custom blocks separately

For custom blocks, verify:

• block registration;
• editor controls;
• frontend rendering;
• block attributes;
• inner blocks;
• dynamic callbacks;
• required CSS and JavaScript.

Check metadata-driven layouts

Some sites store important page content outside post_content.

Examples include:

• Advanced Custom Fields;
• custom metaboxes;
• SEO fields;
• builder metadata;
• custom post-type configuration.

Changing the main editor does not necessarily affect those fields, but the new editing interface may display or integrate them differently.

Custom post types can use different editor configurations

You do not have to make one editor decision for every type of content.

A project might deliberately use:

Posts
→ Block Editor

Pages
→ Block Editor

Products
→ specialized interface

Legacy custom post type
→ Classic Editor

This can be appropriate when different content types have different workflows.

Do not force Block Editor adoption where the content model does not benefit

A structured custom post type containing:

Title
Price
SKU
Technical specifications
Download file

may primarily depend on custom fields rather than free-form page composition.

The Block Editor is not automatically superior merely because it is newer.

Likewise, do not keep Classic Editor purely out of habit

If editors regularly need:

• media-rich layouts;
• reusable patterns;
• structured components;
• columns;
• custom visual blocks;

the Block Editor may provide a more appropriate content model.

For the direct comparison, see Block Editor vs. Classic Editor: Which Fits Your Site?.

Switching editors does not directly change your URLs

Changing the content editor should not by itself change:

• post IDs;
• permalinks;
• slugs;
• publication dates;
• authors;
• taxonomy assignments.

Those are separate WordPress properties.

That means editor switching is not normally an SEO migration

If:

URL stays the same
content meaning stays the same
metadata stays the same

then changing the editor itself is not equivalent to moving the page to a new URL.

SEO problems can still occur if conversion accidentally alters:

• headings;
• links;
• images;
• structured content;
• page layout;
• plugin-generated metadata.

Check internal links after conversion

A good editor migration should preserve existing links.

Test:

• navigation links inside content;
• button URLs;
• image links;
• anchor links;
• shortcode-generated links.

Check frontend performance after migration

Moving between editing systems can change the frontend asset architecture.

A block-based post may load:

• block CSS;
• block-specific JavaScript;
• plugin block assets.

A page-builder layout may load a different asset stack.

The editor itself therefore does not determine performance, but the resulting content architecture can.

Do not disable block CSS before verifying usage

A classic-editor workflow can coexist with existing block content.

Therefore:

Classic Editor enabled
↓
does not prove
↓
block frontend assets unused

Audit the rendered site first.

A safe Classic Editor to Block Editor migration

A reliable process looks like this:

1. Create full backup

2. Create staging site

3. Inventory content types

4. Identify simple Classic posts

5. Identify shortcode-heavy content

6. Identify custom HTML

7. Identify builder pages

8. Open representative posts
   in Block Editor

9. Keep content in Classic block
   initially where appropriate

10. Convert selected examples
    to blocks

11. Compare frontend

12. Test mobile

13. Check forms and embeds

14. Check custom plugins

15. Fix conversion issues

16. Define migration rules

17. Convert gradually

18. Verify again

A safe Block Editor to Classic Editor migration

The opposite direction deserves even more caution when the site contains advanced blocks.

1. Create backup

2. Create staging

3. Inventory block types

4. Identify core blocks

5. Identify custom blocks

6. Identify dynamic blocks

7. Identify nested layouts

8. Test representative posts
   in Classic Editor

9. Do not rewrite complex markup
   unnecessarily

10. Save selected test content

11. Reopen in Block Editor

12. Look for invalid blocks

13. Compare frontend

14. Verify plugin dependencies

15. Decide which posts can safely
    use Classic Editor

The best editor migration may be no conversion at all

Sometimes the safest architecture is:

old content
→ preserve existing format

new content
→ use preferred editor

You do not necessarily need to rewrite ten years of published articles simply because the editorial workflow changed today.

Historical content can remain stable

If an old post:

• renders correctly;
• rarely requires editing;
• contains complex legacy HTML;
• has no business reason for conversion;

leaving its storage format alone may be the most responsible choice.

Convert when conversion provides a real benefit

Reasons might include:

• editors need individual block controls;
• the content requires reusable patterns;
• the site is being comprehensively redesigned;
• old shortcodes are being removed;
• legacy plugins are being retired;
• the editorial workflow is being standardized.

Do not convert merely for database aesthetics

Visitors do not care whether an old paragraph is represented as:

ordinary HTML

or:

serialized Paragraph block

if both produce the same accessible, correct frontend result.

How TheOneWP fits into editor migrations

TheOneWP separates editor controls from frontend block-asset controls because they solve different problems.

Disable Gutenberg controls whether the Block Editor should be available globally or for selected post types.

Remove Block Assets addresses selected frontend assets when a site genuinely does not require them.

Those decisions should remain separate.

A site can use:

Classic Editor
+
existing block content

and therefore still require block-related frontend presentation.

Editor-switching checklist

• Identify the editor currently used for each post type.
• Determine whether existing posts contain serialized blocks.
• Determine whether legacy posts contain ordinary HTML.
• Identify Classic blocks.
• Identify custom HTML.
• Identify shortcodes.
• Identify custom blocks.
• Identify dynamic blocks.
• Identify page-builder pages.
• Identify content stored in post meta.
• Do not assume switching the interface rewrites every post.
• Understand that converting content to blocks is a separate operation.
• Use the Classic block as a compatibility bridge where appropriate.
• Do not bulk-convert complex content without testing.
• Create a full backup before large migrations.
• Use a staging environment.
• Test representative content types.
• Compare editor output before and after.
• Compare frontend output before and after.
• Test desktop.
• Test mobile.
• Check headings.
• Check paragraphs and lists.
• Check images and captions.
• Check galleries.
• Check tables.
• Check internal links.
• Check anchor links.
• Check shortcodes.
• Check forms.
• Check embeds.
• Check custom blocks.
• Check dynamic blocks.
• Check nested layouts.
• Check plugin dependencies.
• Check editor-specific CSS.
• Check frontend block CSS.
• Do not remove block assets merely because Gutenberg is disabled.
• Do not assume page-builder layouts convert automatically.
• Do not remove plugins that provide blocks or shortcodes before auditing content.
• Review revisions where individual conversions go wrong.
• Use full backups for site-wide rollback.
• Consider gradual migration instead of bulk conversion.
• Allow stable historical content to remain unchanged when conversion provides no value.
• Document the final editor strategy for each post type.

Related guides

• Block Editor vs. Classic Editor: Which Fits Your Site?
• How to Bring Back the Classic WordPress Editor
• WordPress Full Site Editing and Block Widgets, Explained
• WordPress Block Editor CSS Explained
• WordPress Staging Site Best Practices
• wp_enqueue_scripts Explained

Final recommendation

Switching WordPress editors does not automatically mean losing your content.

The important question is what happens to the content structure when you begin editing and saving posts through the new workflow.

The safest mental model is:

Switching editor
≠
automatically converting content

and:

converting content
=
potential structural change

Simple Classic Editor articles generally migrate much more easily than pages containing complex custom HTML, shortcodes, nested blocks, custom blocks or page-builder data.

When moving from the Classic Editor to the Block Editor, use the Classic block as a compatibility layer before deciding whether individual content should be converted into native blocks.

When moving in the opposite direction, be especially careful not to rewrite serialized block markup in ways that prevent the Block Editor from understanding it later.

For existing sites, the best migration strategy is usually:

inventory
↓
backup
↓
staging
↓
test representative content
↓
convert only where useful
↓
verify frontend
↓
migrate gradually

And remember that changing the editor, changing the theme, changing the page builder and changing frontend block assets are four different architectural decisions.

Combining all four into one Friday-afternoon migration is technically possible. So is learning why backups exist.