KiraBackup

No. Enable the URL Replacement option during import and enter the destination site URL. The plugin will replace all occurrences of the source URL throughout the database, including inside serialized PHP values used by many themes and plugins.

The new server already runs WordPress, and WordPress itself always comes from WordPress.org. wp-config.php and .htaccess belong to the server: its database connection, paths and PHP settings. While those files would be half replaced — or if a copy from another server did not fit — WordPress could not start at all, and then neither the automatic recovery nor any other way back could run. Your content, users, settings, plugins, themes and media are all in the parts that are restored; translation files (wp-content/languages) are not — WordPress downloads them again. If you need a custom setting from the old wp-config.php, a rule from .htaccess or a file such as robots.txt or ads.txt, copy it by hand.

Until the switch-over nothing on the site changes: the database goes into separate tables and the files are prepared next to the live ones. If the browser tab closes, open KiraBackup again — it offers to continue or to cancel and clean up. If PHP stops a step, the screen shows why; the uploaded ZIP is kept, so you can start the restore again without uploading. The switch-over itself is recorded step by step in a journal in wp-content/wpcbr-tmp/ (inside a folder with a random name, so nobody can download it or the extracted database). Only folders are moved, so even when the journal itself cannot be written (a full disk), KiraBackup stops and puts everything back by looking at what is actually there. If the switch-over stops part-way, the next page load puts the original site back (or finishes the switch when the database had already been swapped), and the KiraBackup screen tells you what happened. A small must-use plugin (!kirabackup-recovery.php, with one "!" more at the start than any other must-use plugin of the site or of the backup, so that it loads first) does this, so it works even when a restored plugin, must-use plugin or theme breaks the site; it is removed when the restore is confirmed or rolled back. After a successful restore, check the site, then click Everything is fine (the copy of the old site is deleted) or Roll back (database and files go back). Without a choice the old copy is deleted after 7 days — unless a person has to decide first (a roll-back was refused, or the restored site lacks much of what it should have); then it is kept until you choose, and the screen says why. If the restored site does not open at all: open the recovery address shown before the restore (…/?wpcbr-recover=<key>), or put an empty file named kirabackup-recover.txt into wp-content by FTP, then open the login page (…/wp-login.php) — it rolls back there. Any other page only accepts it and leaves the work to WP-Cron, which needs the site to be able to call itself (blocked by Basic authentication or some firewalls), or run wp wpcbr recover --rollback --skip-plugins --skip-themes. If even WordPress cannot start, the file HOW-TO-RECOVER.txt in the random folder inside wp-content/wpcbr-tmp/ lists every step to undo by FTP and phpMyAdmin. Rolling back puts the whole site back as it was before the restore: posts, comments, orders, media and settings added after the restore are removed too. KiraBackup asks before it does that.

Yes, when you include the database in your export. WordPress stores user accounts (login names, hashed passwords, roles) in the users and usermeta tables, which are exported and restored. Passwords are stored as hashes and remain valid after migration. Restoring the database replaces the users of this site, so after the restore you log in with the accounts of the backup.

Nothing special to do: the browser always sends the ZIP in slices of a few megabytes. If the server, a proxy or a firewall refuses a slice, it is resent smaller from the same position; if the connection drops, it is retried, and selecting the same file again continues the upload. When even small slices are refused, put the ZIP by FTP into the imports folder named on the Restore tab (inside the backups folder) and choose it there, or run wp wpcbr import <file.zip>.

In a folder inside wp-content with a random name (shown on the Settings tab), and each backup file has a random part in its name. On Apache and IIS the folder also blocks direct downloads (.htaccess, web.config); nginx does not read those files, so there the random names are the protection. To keep backups outside the public web folder entirely, add define( 'WPCBR_BACKUP_DIR', '/path/outside/public_html/kirabackup' ); to wp-config.php.

It is optional. It writes upload_max_filesize, post_max_size, max_execution_time and max_input_time into a marked block in the .htaccess of the site's root folder — where WordPress keeps its own rules (Apache with mod_php) — and into the WordPress folder's .user.ini (PHP-FPM/CGI). It never touches nginx configuration, and it is disabled when DISALLOW_FILE_MODS is set. To undo it, remove that block and those lines. Uploads work without it.

Its settings and job records. Your backups and the restore point are kept, unless you tick Also delete the stored backups and the restore point on the Settings tab before deleting the plugin. A restore that is waiting for Everything is fine keeps its recovery helper, so it can still be rolled back; with that option ticked, the copy of the old site is deleted too.

No. On a Multisite network the plugin stays inactive, because a restore would overwrite the tables and files shared by every site.

KiraBackup is the same plugin under a new name. Deactivate Complete Backup Restore, activate KiraBackup, then delete the old plugin. Your stored backups and restore point carry over, and backups made with the old version can be restored.