The project was to restore a WordPress Multisite from the backups of an old VPS, where it had previously been hosted, to a new hosting service. The backup files were not WordPress specific, but were of a full-system backup for the VPS, taken just before it was shutdown several months earlier. Fortunately, this also included a complete dump of the database in addition to the hosted website files.
The first order of business was to extract just the file area of the previously hosted website, in addition the SQL dump file of the database, from the system backup files onto a local machine.
We then logged into the cPanel of the new hosting provider and manually uploaded the latest release of WordPress. A new empty database was created in the providers MySQL service to be used by the restored website and it's credentials added to wp-config.php, the configuration file on the new WordPress installation.
Double checking the configuration file from the original installation, we found that WordPress had been using a custom database prefix, so we adjusted our new wp-config.php file to match and also copied over the configuration entries related to running in Multisite mode.
The new WordPress's wp-content folder was replaced with the version restored locally from the backup files, restoring all the themes, plugins, and uploaded images and other files that had been in place on the original website.
And finally, the database was populated. This required extracting just the relevant WordPress tables from system-wide SQL dump file we recovered from the backup files and importing them into the data service using phpMyAdmin on the hosting provider's cPanel. Fortunately, the website was going to be restored using it's original URL, so we didn't have to make any changes to the SQL file. However, when we attempted to import it, we discovered it was too large to be handled by phpMyAdmin. So we manually split the file into two coherent chunks, each of which could be imported into the database service. This restored all the user accounts, sites, pages, posts, and Media Library entries.
Since the new WordPress install was newer than the original one, the first time we logged into it as the administrator account, it detected the version difference and "upgraded" the database structure for the version we were now using.
This particular Multisite setup was a subdomain-based Multisite, meaning that the members in its website network were all subdomains of the parent domain. So we also had to update DNS to allow wild-card hostname lookups, and setup the hosting provider to map wild-card subdomains to the current website installation. This allows the WordPress Multisite to handle requests for domain.com, billy.domain.com, and ralph.domain.com, showing the proper website for each of them.
Success! The Multisite network is just as it had last been when the VPS server was last backed.
The next step will be to setup a WordPress specific backup to run on a regular schedule that will also automatically store the backups files at remote location, such as Dropbox, Google Drive or elsewhere. Having WordPress specific backups will make restoring the site much, much easier the next time around.