It is that time again – Spring. For the moment, the sun is out here in Massachusetts and the birds are chirping away. Spring means that yet another version of APX has been released. Though APX releases are frequent, APX users tend to upgrade when it makes sense for their firm and not necessarily the moment a new version is released.
As a result of these frequent updates, there are a wide variety of APX versions in use today. You might find someone running APX 3.x and someone else running APX 18.x. Years ago, Advent changed their release naming convention to align with the years. Since that point they do two new releases per year – one in April and one in October. This year will see APX 19.1 and 19.2 released.
Advent tried to do the same thing with Axys, but as far as I can tell they were never able to get a large number of users to adopt the to the newer versions that they released. As a result, you will find Axys users typically on a version somewhere between Axys 3.7 and Axys 3.8.7. Axys 3.7 was released a long, long time ago; Axys version 3.8.7 just came out in the past six months. Most Axys users should now be on version 3.8.6 or 3.8.7, but I wouldn’t be surprised to see Axys users still running 3.8.5.
Over the years I have spent consulting to Advent customers, I have seen many Axys users make the switch to APX. Users moving from Axys to APX usually do so at a significant immediate and ongoing incremental expense. For some firms the migration to APX it is a natural progression that can complement an aggressive budgetary commitment to technology that includes employees or contractors with the skills and experience to take advantage of the SQL back end.
For other firms, moving to APX could be a waste of time and money – given their needs and the level of commitment they are willing to make to retain the technical expertise necessary to take advantage of the enterprise features inherent in APX.
While adding SQL to the mix, APX also adds a layer of complexities that typically includes multiple servers as well as individual user rights to datasets and applications. These added complexities can ratchet up the difficultly level to a point where IT and operations staff need to work together to resolve APX issues more frequently.
In short, APX isn’t for everyone. As such, it should come as no surprise that some firms that have made the switch regret it and approach me seeking a way back to Axys. Users that want to go back to Axys definitely can, but the process can be somewhat challenging.
Advent APX to Axys Conversion
In order to convert from APX back to Axys you need to do the following:
- Get an Axys license if you need one.
If you have a recent Axys license that doesn’t expire and you aren’t going to be using Advent’s support resources you may not feel that you need a license, but if you are planning on using Axys long-term it may be wise to update your license and sign an ongoing support agreement for Axys. Windows 10 is an ever-changing operating system. Without an ongoing Advent maintenance agreement, I would be concerned that future Windows 10 updates may make break Axys and eventually require patches from Advent to continue working in Windows 10.
- Export most of your data from APX.
Using IMEX, export everything you can to Axys 3 format: prices, portfolios, splits, security information, sectors, industries, asset classes, indexes, composites et cetera. Many of these files can then be imported back into Axys with very little work. However, you will run into at least two problems that require additional work: performance history and portfolios. Depending on what version of APX you are using, trying to export performance history via IMEX that you want to import back into Axys will lead to frustration.
- Export and import your performance history.
Use the Performance Extract Report under the performance section of APX reports to build gross of fees (PBF) and net of fees (PRF) files that are compatible with Axys 3. Once these files are exported, they can be easily imported into Axys again.
- Export your portfolios and map them into the Trade Blotter.
As with any conversion to a different portfolio management system, a decision needs to be made regarding transaction history. It is far easier to simply go forward in time without transaction history, but usually less desirable from management’s perspective. Though you can export portfolios using IMEX, Axys doesn’t let you import portfolio (CLI) files. Every transaction that goes into a portfolio needs to go through the trade blotter. This limitation may seem arbitrary, but it ensures that any record posted through the trade blotter is also stored in the audit trail (didpost.aud) file for record keeping purposes.
In order to import your portfolios, you’ll need to map the transactions from the exported CLI file to the trade blotter format. That is usually where someone like me gets involved. I have created a tool that I use as a template to get started with the process. The tool takes portfolio (CLI) files exported from APX and builds an Axys trade blotter (topost.trn) from those portfolios. However, that tool only works with the transaction mappings that have already been created. Working with another firm’s data and unique transactions usually requires additional coding to map new and/or unique transaction types.
Please note, reconstructing tax lots to match your original files can be difficult, so the endeavor of converting historical transactions from APX to Axys shouldn’t be taken on lightly, but It is certainly possible for those that decide it is important enough to merit the extra work and cost involved.
In addition, readers should note that converting from APX to back to Axys seems fairly uncommon to me. A large part of the costs associated with moving to APX are sunk costs, so converting back to Axys only helps with the ongoing cost. However, the ongoing cost of APX can be prohibitive.
It is worth mentioning that there is also more than one way to get APX and the cost of these APX implementations can vary significantly. Cost alone should not drive APX users back to Axys.
Advent users can elect to:
- self-host APX in their local environment
- have APX hosted by a service provider that is not Advent
- have APX hosted by Advent in a dedicated environment
- have APX hosted by Advent in a multi-tenant environment.
With respect to cost, I believe having APX hosted by Advent in a multi-tenant environment is the least expensive option, but it can also severely limit what users can and cannot do within their shared APX environment. Likewise, having APX hosted by Advent in a dedicated environment can be complicated by Advent’s oversight and rules to what you can do in your own “dedicated” environment. Given these limitations, my personal preference for APX is to host it in a local environment or with a service provider that is not Advent.
About the Author: Kevin Shea is the Founder and Principal 
Consultant of Quartare; Quartare provides a wide variety of technology solutions to investment advisors nationwide.
For details, please visit Quartare.com, contact Kevin Shea via phone at 617-720-3400 x202 or e-mail at kshea@quartare.com.