Hi Rick, I’ve checked the migration code, and this looks like it could be getting stuck while finishing the backup ZIP. The Twig filename is probably just the last progress update, rather than a problem with that particular file. The counter updates every 200 files added to the archive, but the compression/write step happens afterwards and currently doesn’t report progress. NGINX or PHP-FPM timing out during that quiet period could explain what you’re seeing.
There was a related fix in migrate-grav 1.0.15 that excludes caches, logs, temporary files and previous backups from this backup, which substantially reduces the work involved. One catch: the wizard is copied to migrate.php in your site’s root directory when you first start a migration. Updating the plugin afterwards doesn’t update that existing copy when you resume. Since your original attempt was back in July, you may still be running the older wizard.
Could you check your migrate-grav plugin version, and search the root-level migrate.php for MG_BACKUP_SKIP_TOP? If that text is missing, the wizard doesn’t have the backup fix.
If it is the older copy, update the plugin to 1.0.15 or newer, then, once the previous migration request has stopped running, copy:
user/plugins/migrate-grav/wizard/migrate.php
to migrate.php in the original site’s root, replacing just that file. Keep .migrating and your grav-2/ directory intact, including the pages you copied manually, then reopen the existing wizard URL and retry Promote. Don’t use Reset Migration or Restart Wizard for this, as those remove the staged install.
If your root-level wizard already has the fix, please check the NGINX and PHP-FPM error logs at the time it stalls, and whether a file in grav-2/backup/ continues growing or disappears. NGINX’s fastcgi_read_timeout and PHP-FPM’s request_terminate_timeout would be the next things to check. That should help distinguish a connection timeout from the backup process itself failing.