Support

In your specific use case I would recommend the following course of action:

1. Do your migration work on the test site as you already explained.
2. Before you go love, take a backup of the test site and keep that backup in case something gets messed up :)
3. Uninstall ATS 5 (the Joomla 4–only version) from the test site. It does not remove any categories, custom fields, menu items etc because of the more naïve way its uninstallation works. We will use that to our advantage!
4. Install ATS 4 (the Joomla 3 and Joomla 4 compatible version) on the test site.
5. Copy all the #__ats_* tables from the live Joomla 3 site into the Joomla 4 site, making sure that the table prefix matches the one you are now using on the Joomla 4 site.
6. Install ATS 5. This upgrades all the database tables to the new format.
7. Test that the site works as intended.

At this point you have confirmed that the test site is ready for deployment. In the meantime, some tickets may have been created / replied to on the live site. So, let's get ready for D-Day (deployment day!).

1. Prepare a simple off–line HTML page with a notice that you'll be back in a couple of hours. Upload it to your site as offline.html. We will be using that while the site restoration is in progress to keep unsuspecting members of the public away from our restoration.
2. Set the test site off–line with a notice that you'll be back in a couple of hours. That's the same notice as step #1; we want to provide continuity.
3. Set the Joomla 3 site off–line with a notice that you'll be back in a couple of hours. This is the same notice you used in step #1 for the same reason.
4. On the test site, repeat steps 2–6 from the instructions in the previous section. This will make sure that your test site has up–to–date ticket information.
5. Take a backup of the test site.
6. Upload the backup and kickstart.php to the live site.
7. Run Kickstart. Make sure to select the Stealth Mode (it will display the offline.html file to users while the restoration is in progress) AND the Delete Everything Before Extraction options before pressing the Start button. The latter removes the Joomla 3 site's files; if you don't do that your restored site will be broken.
8. Once the archive is extracted press the Run The Installer button to launch ANGIE, the restoration script.
9. In the Database Restoration page set With Existing Tables to Drop Same Prefix. Also make sure that the Database Table Name Prefix option is identical to the prefix you were using on the Joomla 3 site. This will make sure there are no leftover tables from your Joomla 3 installation.
10. Proceed with the restoration, do the cleanup.
11. Finally, remember to log into the live site's backend and set the Site Offline back to No.

Magic! Your users now see the brand new Joomla 4 site without missing any ticket information previously entered on the Joomla 3 site.

We have used this very same process several times in the past e.g. upgrading from Joomla 1.5 to 2.5, 2.5 to 3.2, our site redesign back in 2016, moving servers in 2014 and 2020. A cut down version of that process was used in the past for minor redesigns as well.

Some tips.

Transferring the database tables can be a pain in the rear. Use a new Akeeba Backup profile with the backup type set to ”All Configured Databases (Archive File)”. Use the database table filters to exclude all tables except the ones which belong to ATS. You can then use Kickstart to extract the JPA archive and Run The Installer which brings up ANGIE, the restoration script which was included in the backup archive. This is much more user friendly than trying to use phpMyAdmin on both sites.

Before doing the go–live process on the live site I always test on a subdomain on the site's server. That's a staging site. I start by making a backup of the live site and restoring it on the staging site. Then I carry out the go–live process on the staging site. If I find any issues I document them, work around them and update my go–live steps. Then I repeat the process from scratch. Once I am satisfied that I can do the go–live process with my eyes closed so to speak I do it for real, on the live site. Finally, I dispose of the staging subdomain.

Akeeba Backup was explicitly designed for this kind of scenarios. That's the problem I was trying to solve back in 2006: deploying sites. It just so happens that deploying sites with an archive is also a backup copy of the site. People were looking at the time for a way to take backups, not deploy sites, which is why the software (called JoomlaPack at the time) was renamed to Akeeba Backup in 2010 and more backup–specific features were added to it. It still is very much a site deployment tool.