Case Study: Sometimes a WordPress Import Isn’t Quite So Simple
Back in the old days of the web, we built “static” sites. That means that the content and the coding were all lined up between and around each other in files. It also meant that taking a copy of the content to move it into a different design was more difficult. Nowadays, the content is often in a database, separate from the files that make the design, so separating the two is easier. How easy depends on the technology used.
WordPress has a handy-dandy export function that comes with the basic WordPress install. That means that it’s part of the WordPress core, not a plugin. (There are also plugins for this task.) 
When you use the Export tool, you can choose what you want to export.
One situation where this tool is helpful is when you are rebuilding a site on a new web host. You can do a basic WordPress install on the new host and import the Posts, Pages and other structures from the export of the old site. New versions of WordPress also give you the choice to export custom data types and information that is held in plugins. 
In the example on the right, you can see that MetaSliders and Content Blocks are included in the export options.
But, the export might include some unexpected data too, as a client recently found out. Sometimes that data is created by an unwieldy theme or plugin that you are trying to make a thing of the past!
The Avada Nightmare
Based on the comments I have seen in WordPress forums, many people like the WordPress Avada theme. Generally, they aren’t the folks who code because they haven’t seen a site with approx. 2000 lines of internal CSS code created by Avada in the home page of a website. They probably haven’t checked the code either. Avada has other issues, as well, but just that one is enough for me to say, “Enough of Avada.”
In a recent web host and theme switch for a client, I found another, hidden, problem with Avada. Every Post and Page had 56 custom post fields. The image on the left shows some of these fields. A careful review of the field names shows that each field is an Avada setting that allow you to customize each Post and Page layout.That is part of the overhead of the Avada Builder tool. Now, I know where all that internal CSS is coming from. Supporting the custom post fields is a significant amount of PHP.
None of the structures on their own is a problem: Custom Post Types, the postmeta table where these value go, or the PHP code. The situation we are discussing comes when the Posts and Pages are exported to import into a new theme, and fields that do not contain an actual part of the information is imported with it. The custom post fields are formatting, not content. So, the new theme has no use for the data in these fields. With a standard content import, we now have extraneous data in the new database.
The Clean-up
Clean-up in a relational database always requires care because a record in one table may have references to one or more records in other tables. This is done with the use of foreign keys. Each record in the postmeta table has a foreign key to a post in the post table. That attaches the record in the postmeta table to a specific post. It also means that every single post has a record for each of these fields in the postmeta table. That’s a lot of clean up.