Categories
Latest News

Linetime liberate Axxia site

Maritime lawyers Winter Scott are investing in a Linetime Liberate practice and document management system to replace their Axxia software. An element in securing the contract was Linetime’s ability to migrate the existing data.

8 replies on “Linetime liberate Axxia site”

“An element in securing the contract was Linetime’s ability to migrate the existing data.”
Surely every swap out from one system to another will involve migration of existing data, so all vendors will have this capability.

I think you've answered your own question, whilst all vendors have the “capability” have they the “ability” to carry it out ?

Exactly. Theoretically there is nothing new about data transfer but you still hear horror stories.

Quite the opposite.
Depending on which system you and migrating from and to, data migration can be a fairly straightforward exercise or the cause of complete project failure.
Typically:
1. Document Management: Transfer of documents and associated metadata between two systems is fairly straightforward. It's easy enough to export the document files, and metadata fields can be mapped one to one or transformed between vendor databases readily with minimal translation or verification.
2. Case Management/Workflow: The more complex/detailed/prescriptive the workflow rules in a system, the harder it is to transfer ongoing matters to another system. The 'state' of each matter at the point of transfer must be be mapped on to the new workflow; populating data fields, setting status flags, following logical branches and creating the correct reminders and future workflow tasks.
The problem is generally consigned to the 'too hard' pile of project activities. You can get away with it if matter life-cycles are short (e.g. domestic conveyancing work) as you just run off matters on the old system and incept new matters on the replacement. For long-tail litigation running over several years, this issue can be a significant barrier to implementing a new product; either you spend a fortune devising complex conversion code, pay a small army of people to manually re-key completed parts of each matter's workflow on the new system, or you bear the costs of running two systems in parallel for two or three years. None of these options are enticing prospects!
3. Accounts/Billing/Financials (PMS): Data conversion the most significant implementation challenge to consider during the selection and pre-contract process. It is typically the longest, most labour-intenstive and critical process required to implement the new system. Under-estimating the difficulty involved has caused many PMS projects to stall and a significant few to founder (you rarely hear publicly about these failures because the subsequent settlement always involves a confidentiality clause and occasionally an upbeat press release about a strategy review necessitating a change of vendor).
The difficulty of the PMS conversion process depends on many interacting factors, including:
– How willing the incumbent supplier is to assist the new supplier in devising an extraction and conversion process. The answer is usually 'not very', but there are some exceptions.
– The database technologies in use (usually arcane) and how easy it is to understand the database structures. Also whether the PMS database truly integrated with the case/workflow/document database, or are they two products masquerading as one.
– How much in-house knowledge the firm has about the current system and how it has been used over its life. Changes in internal procedures and polcies, previous mergers (resulting in imported/converted data), and many other things can make it hard to convert historical data consistently.
(If you get stuck due to lack of historical knowledge, I always suggest give these guys a call: http://www.legacy-support.co.uk/).
– How much current and historical data do you need to convert? Anywhere between opening balances or full history across all transactions and tables?
– Can you map all significant data from one system to the other or are there gaps that will cause you to lose data (from the old system) or that you will need to populate (in the new system)?
This latter issue is significant when migrating from a legacy system to a modern PMS. You will always have a lot more holes to fill than you have data to fill it with. Those sexy slice and dice reports you saw in the sales demo are a lot less useful if every result has 80% of the values in the 'CONVERSION' category!
– Does the new supplier have past experience of converting from your current system or are they going to have to work it out from scratch?
There are no easy answers to the data conversion problem. On the plus side, you can usually gauge your chances of success by how willing the new supplier is to commit to a fixed cost and time-scale for doing the conversion, and how clear they are about what will and (more importantly) will not be converted for the agreed price.
Just as importantly, what is the supplier's attitude towards working working through the inevitable problems that will arise, and is that backed up by their reputation in the marketplace? Hard to be sure, which is one factor contributing to a fairly typical 12 or 18 month selection process.

Come on, most of the bigger and mid sized PMS suppliers can do PMS conversions, and in my experience most will offer a fixed price for doing it and do a decent job of it. I suspect that the real reason it was used as a “quote” was it the best neutral statement that the client would sign up to. Nevertheless a nice win for linetime.

– Does the new supplier have past experience of converting from your current system or are they going to have to work it out from scratch?
Does not matter – every single legacy system will be be set up one way and every new one will be set up differently too. So one conversion from A to B will not mean the next one will work too. They are all separate projects. And something all vendors are capable of (just means time and resource – and therefore money).

Migrating from Axxia is a nightmare, because so many of the tables don't hold the full transaction detail, and rely on summary totals, leading to lots of “CONVERSION” adjustments.

I've converted sites from Axxia previously and never had a problem.
Everybody offers transaction level detail as pretty much standard, and althought time consuming and painstaking, I've always successfully migrated.
An earlier commentator rightly picks up case as the grey area. In recent years my experience has been largely limited to takeovers and mergers and because of timescales, it hasn't been possible to spend the time necessary to complete. There is also an issue that often case represents a maximum of 20% of a firms workload, so it doesn't make economic sense to invest all your time in that arena. Finally, when you're doing a merger, the contracts from the previous supplier need time to wind-down, so you do end up, generally, leaving the active cases to dribble their way through the old system.
In my experience the main factor that causes problems with data migration is the desire to expand the exercise into BPR. It is a great opportunity to revise working practices, but often firms do not appreciate just how much disruption this is going to bring to their business, and how much time and effort is needed to make it a success; failure generally comes down to under-resourcing these aspects or over-reaching.

Comments are closed.