I am not an expert at ATX administration. It's something I've come to reluctantly, and I spend as little time on it as I reasonably can. I've made it work, but my range of experience is limited. I'm writing this because there seems to be a dearth of publicly available information on ATX administration. Your mileage may vary.

The basic idea of ATX's recommended approach is to take the entire ProgramData folder for a given tax year from the old computer, such as C:\ProgramData\Wolters Kluwer\ATX 2021 Server, copy it to the new server, and then install the ATX server software "on top of it". When the new server software starts, it will find its data in the expected location and will use it. When you open the client application and point it at the new server, it should just work.

Unfortunately, this assumes that the database files within that program-data folder are compatible with the JET database engine on your new computer. When I used this approach to migrate from a computer running Windows 10 Home to a computer running Windows Server 2016 Datacenter (on a virtual machine hosted by ACE Cloud Hosting), I discovered that every time I started the ATX client application, I got an error: "unable to self-repair the database".

I chatted with ATX tech support, and they recommended that I run their database repair script. I tried this for ATX 2019, but I got an error when I attempted to run esentutl:

JET_errInvalidDatabaseVersion

I tried researching the error, and it sounded like the JET engine on my Windows 10 Home computer might be newer than what's on the Windows Server 2016 server, which could explain why the data I copied from my server was unreadable.

When I ran this command on the data copied from my own server...

esentutl /r rvn /s system /l logs

...I got this error:

Operation terminated with error -514 (JET_errBadLogVersion, Version of log file is not compatible with Jet version) after 0.31 seconds.

I spent easily five hours trying to resolve this issue, but got nowhere. Since ACE Cloud Hosting couldn't offer a JET upgrade nor a newer operating system at the time, and they seemed to be the best game in town for cloud hosting of tax software, I decided to look for other ways to get all the data to the new computer.

Unable to use the recommended approach, I saw two alternatives. The obvious one, to me, was to use the backups that ATX provides for undoing mistakes, recovering from data corruption, etc. Looking through forum posts, I found another possibility: export all returns from the original computer, then import them on the new computer. I honestly don't know yet whether one of these approaches is inherently better than the other. I'll just walk you through mistakes I made along the way, in the hope that you can avoid making them, too.

ATX provides two backup mechanisms, for:

The first mistake I made was to take the entire backup folder and restore all the returns. The problem here is that backups for deleted returns hang around in the backup folder forever. I didn't want to sift through all the restored returns and figure out which ones should not have been restored. I looked for a tool within ATX that would allow me to back up all non-deleted returns, but I couldn't find one — not without manually check-marking them all in the Backup screen, which is time-consuming because there's a limit of 100 returns per page. So I tried the export-import technique instead, since ATX offers a straightforward method for exporting all current/non-deleted returns.

The second mistake I made was to not back up Setup Data and restore that on the new computer. The export-import mechanism completely bypasses setup data, so you'll have to do that part manually.

Given that I was unable to use ATX's recommended approach of copying over the entire program-data directory, here's how I would do this next time.

During the Import process, ATX reported an error, presumably on all returns with fixed assets: "The program was unable to load fixed asset data. Please try importing fixed assets to add them back to the return." I dismissed each error and allowed the import process to proceed.

My research turned up very little about this issue. One forum user reported that they ignored the error and never saw any problems with the imported returns. I found no mention anywhere of a separate process for importing fixed assets. So far, we've found no actual problem with fixed assets. Perhaps this is a bug in ATX left over from the integration of third-party fixed-assets software into their product? If I find out that there were in fact problems, I'll try restoring the returns in question from backup, to see if that works any better.

This is a time-consuming, very hands-on process, and the fixed-assets errors make me nervous. If I had been working with my own hardware, instead of ACE Cloud Hosting, I would have fixed the root database-incompatibility problem by installing a different operating system on the new computer, so that I could use ATX's recommended approach. However, the fact that the recommended approach relies on compatible JET database software means it has an inherent vulnerability to failure. I wish ATX had a "one-click export" process that exported all returns, all companies, all custom forms, all setup data — EVERYTHING I need to move to a new computer. Better still, since I like to automate admin procedures, would be an export-all command-line tool. I would schedule this to run every day, and I'd save the output to an external or remote drive, to give me the peace of mind that comes from knowing I can reliably restore a mission-critical server in under four hours, should disaster strike in the height of Tax Season. But ATX comes at a price point where features like this can't be expected.

Additionally: since ATX does not automatically back up Setup Data, I strongly recommend you do so manually and keep a copy of that setup data handy in case of emergency.

My wife, who runs a small accounting firm for small businesses called The Dancing Accountant, has used ATX as her tax software for nearly as long as it's been a product. She has struggled through its growing pains and accepted its limitations, and has ultimately decided that for a firm as small as hers, which does somewhere in the ballpark of a hundred returns each year, moving up to a more expensive package can't be justified. (The package she would choose is four times as expensive.) ATX has delivered everything she truly needs; it's just not as technically capable as we would like.

I'm a software developer and occasional writer of fiction and poetry. I also do IT work and custom software and Excel projects for my wife's accounting firm. If you found this helpful, you'd like to thank me, and you enjoy reading — or know someone who does, or just want to do me a favor in return — buy one of my books!