Yikes! You've got a server migration, an upgrade, and a restore that are being tackled all at once. The httpd process was probably trying to call the migration handlers, but was unsuccessful due to the code jump at restore time from 7.4.4 to 7.6.2 without proper database migration (database migration typically happens during upgrade).
Key things to keep in mind:
a. Upgrading from 7.4.4 to 7.6.2 is okay as you can upgrade between 2 releases skipping 1 major release (skipping 7.5 in this case).
b. Restores need to be made based on release versions, a 7.4.4 AMP backup will restore clean on a 7.4.4-7.4.9 (7.4.9 was the last release of 7.4). A 7.4 backup will not cleanly restore on a 7.5 or 7.6 version due to schema changes in the database (where database tables or columns have been changes, added, deleted, or even split).
The clean way to get you back online (my recommendation) -
1. Delete the new VM instance that was installed with 7.6.
2. Create a new instance, installing 7.4.9 ISO
3. Restore the 7.4.4 backup
4. Upgrade to 7.6.2
-> this will get you to current AMP code
If you were trying to do this to upgrade the OS, then add these steps:
5. Take backup of 7.6.2
6. Pull backup off server
7. Power down instance (At this time, you may delete the instance, I keep it around in case something went wrong with the backup to save me from going back to step 2)
8. Create new instance, installing 7.6.2 ISO
9. Restore 7.6.2 backup
10. Delete intermediate instance that was power down in step 7 if you haven't already done so.
The alternative (okay for lab, but not for production), there's a battle of risk and reward here:
# root; make
This command should call for the database migrations that were missed when the upgrade process was never called. The risk is if the database changed to a point that the restore did not put anything in the database. This is more likely to work if the upgrade is spanning 1 release, but the scenario you put together is upgrading a span of 2 releases.