The ‘slots’ where sections can be added to pages are called Areas. Configurable pages (custom pages, articles, area guides etc) should support the four area types:

Areas can be added to the .site.tsx pages using the <Area> component:
<Area sections={pageConfig.areas.header} availableSections={sections} fallbacks={fallbacks} />
and they should be added to the .admin.tsx version using <LazyOrderableSections>, which allows the admin drag-and-drop features:
<LazyOrderableSections areaName="header" />
If the areas design needs an update to for example change position:

And you have sections data in the area(s), one solution could be moving all the area sections data, from one area to the other.
To perform the trick you will need to have Mongosh installed locally (no, sadly this can not be done in MongoBD Compass, no, not even in the dedicated command line tool)
The following command example was used to perform the trick, but you can tweak to suit your task:
db.pageConfigurations
.find(
// Here you run the search for the documents you need to update (1)
{ agencyId: 904, page: 'branch', 'areas.main': { $exists: true } }
)
.forEach((doc) => {
// Merge the sections in the order you need (2)
const mergedSections = [...(doc.areas?.main || []), ...(doc.areas?.secondary || [])];
db.pageConfigurations.updateOne(
{ _id: doc._id },
{
$set: {
// Overide the target area
'areas.secondary': mergedSections,
},
// Delete the origin area, or you will have duplicated sections
$unset: {
'areas.main': '',
},
}
);
});
To make sure you only target the pages intended to, run first the query on its own (in Compass works better for visualisation)
Set the correct order, and keep in mind that target area might be empty/null so always default to empty array ...(doc.areas?.secondary || [])
Test thoroughly the query worked as expected. Recreate as much as possible all the case scenarios (empty target area, not empty target area, document with other areas that shouldn’t change, etc)
If satisfied, ask Mark and/or Bob in #tech-production-data-request to run in production, not without keeping a backup in case of a rollback.