Posted by oren on Tue, Jul 01, 2025 - 11:20am

Hi all,

I'm doing my first BackdropCMS site migration, following this official guide.

I've already gone through all the steps listed there, but I realize that after an apparently successful configuration and database import, that many of the configurations didn't migrate over successfully, despite no errors when I exported & imported the entire site configuration. Which has resulted in orphaned or lost field data.

For example, some custom content types, fields, field instances and views didn't import over at all.

So, I've been manually importing various configurations one by one using the single import/export feature.

The thorniest issue I'm hitting so far is a situation like this one:

There was a problem creating field Paragraphs: The field "field_paragraphs" could not be created because a database table with the name "field_data_field_paragraphs" already exists.

As of now, using the content type UI, I can't seem to manually create the field instance without choosing a different field instance name.

Any tips?

Accepted answer

Ah, I see. Sorry, I hadn't clicked the link and assumed it was the instructions for upgrading from Drupal 7.

If you are simply copying a site from one location on a server to another, the language of "migration" seems off to me. I think all you'd need to do is make sure that these items are copied into the respective locations:

  1. Database (imported)
  2. Filesystem updated (incl. core, contrib, and files directory)
  3. Active configuration folder updated (if it wasn't already copied and you are using the default file-system-based configuration)

At that point the site should just work without a separate migration step needed.

Most helpful answers

This doesn't sound right --

This doesn't sound right -- when the upgrade completed, did you export the post-upgrade configuration into the staging folder (and commit that to the repo if you are using a git-based workflow)?

One possibility, though. Were the missing content types, etc. all created using Features on the Drupal 7 site? Or were they just standard, created through the UI?

Comments

Tue, Jul 01, 2025 - 11:23am by laryn

This doesn't sound right -- when the upgrade completed, did you export the post-upgrade configuration into the staging folder (and commit that to the repo if you are using a git-based workflow)?

One possibility, though. Were the missing content types, etc. all created using Features on the Drupal 7 site? Or were they just standard, created through the UI?

Tue, Jul 01, 2025 - 12:32pm by oren

Thanks for the quick reply, laryn.

No features, no Drupal: I built the source site in Backdrop in a subdirectory of the target directory under the same user home directory on the same cpanel shared hosting environment.

No, I haven't installed a git repo yet, because this was my nth attempt and I fear I may need to re-run the migrate procedure all over again.

I don't see "exporting the post-upgrade configuration into the staging folder"...in the the guide that I linked. But I did "Import the configuration gz file exported in step 1." Is there another additional step I should take not listed in the linked guide?

Any other troubleshooting you can suggest at this stage, or any additional steps you would recommend I add into the process if/when I begin the migration all over again? I have access to bee cli.

Tue, Jul 01, 2025 - 2:05pm by laryn

Ah, I see. Sorry, I hadn't clicked the link and assumed it was the instructions for upgrading from Drupal 7.

If you are simply copying a site from one location on a server to another, the language of "migration" seems off to me. I think all you'd need to do is make sure that these items are copied into the respective locations:

  1. Database (imported)
  2. Filesystem updated (incl. core, contrib, and files directory)
  3. Active configuration folder updated (if it wasn't already copied and you are using the default file-system-based configuration)

At that point the site should just work without a separate migration step needed.

Tue, Jul 01, 2025 - 4:35pm by oren

Thanks so much! It's working now:

I was able to transfer the docroot files to the containing directory without the need for a second database or any manual configuration export/import/sync operations.

My first attempt a few days ago had been to try this shorter method. After a simple copy over of the files, the site index would load, but everything else produced 500 errors, and with no access to PHP or Apache errors on this host, I resorted to the full Backup & Migrate guide I linked above as a (lot of extra) workaround.

In looking back, think the initial error was simply due to hidden files (particularly .htaccess) not being copied with my cp -r subdirectory/* . command.

Everything is snappy and smooth now. Thanks so much to all the backdrop community for this amazing tool!