Picture credit: Flickr
Just like birds migrate, businesses from time to time
also need to migrate their data from one system to another. Elkie Holland caught up with Nick Tippetts of
Pick2SQL. Nick is a MultiValue stalwart but who has surprisingly started a
Migration / Data Extraction business. Elkie Holland finds out more:
ELKIE: Why did a MultiValue stalwart begin to do
migrations and data extractions out of MultiValue solutions ?
NICK: The decision was client driven; the more requests we began to get the more it became imperative that we focus on this as a service rather than the odd request, here and there. This would then benefit the user in speed of service and price.
ELKIE: Is there a specific client type or vertical market that you’re seeing most requests from?
NICK: Not really, although financial services, stock control and contract billing appear to be the most frequent.
ELKIE: When talking to clients is the primary driver for your service technical, commercial or political?
NICK: Usually a combination of all three. The most common is when an organization is taken over and the new owners have a single database policy and they want commonality. In that sort of situation there is little choice. If you attempt to fight the MultiValue corner 9 times out of 10 you’ll lose and because of the atmosphere created you’ll lose any potential business. The second most common is the requirement for technical change such as hardware longevity or de-commission a computer room or comms centre. Both examples have, in no small part, a commercial aspect.
ELKIE: Why are clients turning to you?
NICK: It’s simple really. Either the original system vendor isn’t around anymore or they have moved out of the MultiValue sector. Those vendors still left in the sector are not as open as they could be to migration out of the MultiValue sector and therefore try to move them forward but on another more recent flavour of our favoured RDBMS. This is fine but if the motivation for the move is driven by the necessity for commonality it’s never going to happen.
ELKIE: Are there instances where the extraction service can sit alongside an existing MultiValue application?
NICK: Yes. There are a number of scenarios that can see a legacy application running alongside a new one. In some cases the new application is seeded from the legacy application (with a data extract) and is used to drive new areas of business for the client whilst the legacy application continues to service other established sides of the business. In some cases the new and legacy applications can be configured for bi-directional communications in a closed loop.
ELKIE: Are you limiting what you do to a SQL end result?
NICK: Not, at all. Depending on the client’s requirements we can provide various levels of solution. If the client requires a simple extract to a series of common files or a complete application constructed based on contemporary technology we can usual meet those requirements - and any point in between. We have extracted data from a financial trading application and delivered in CSV format for onward population of a global trading platform. We have also developed a number of browser-based applications with a SQL backend populated from legacy platforms and recently we have revived a long dead taxi billing system by constructing a MS-ACCESS application containing 30 years’ worth of crucial business data. SQL, MS-ACCESS, Excel, CSV, XML, ORACLE, Sybase, it really is up to the client.
ELKIE: What’s the most challenging request you’ve had so far?
NICK: As you know a lot of legacy MultiValue systems were originally based on serial only machines and some of these have not been migrated onto other platforms. In most cases the old ¼’ tape deck no longer functions and the systems haven’t been backed up for a little while. This situation is more common that we’d like to think. So this usually requires a serial cable and a decent terminal emulator with reliable data download capabilities and a lot of patience. Thankfully these systems don’t contain gigabytes of data but at serial speeds it can take a while.
ELKIE: Would there be any situations either technical or political where you’d question getting involved?
NICK: Obviously I’m going to say no, but that’s a little cavalier. However, with a history stretching back a few years we’ve encountered our fair share of “issues” and we’ve usually been able to provide a solution. From situations of client data confidentiality/security to military programs which required, in some cases, a man in a room with only console access. We’ve probably dealt with most eventualities and are therefore capable of covering most situations.
ELKIE: Do you not see this as turning your back on your MultiValue roots?
NICK: Not at all. Our clients have, in most cases, invested huge sums of money in the MultiValue sector over many years. All they want to be able to do is maximize the potential of the data and business knowledge contained within their MultiValue applications without being restricted to an increasingly small number of vendors and support staff capable of providing the required support and service for their applications. As the percentage of our business that is MultiValue based decrease, this is the ideal way to maximize the legacy knowledge of our existing MultiValue literate staff. Whilst still being able to leverage a MultiValue solution wherever possible.
ELKIE: With regard to the source systems/application, are you looking to expand the service beyond the MultiValue sphere?
NICK: Our initial focus has been on the various flavours of RDBMS prevalent in the multivalue world. However, I suspect, when the request comes from a client with a FoxPro database on an ancient Banyan vines server, we’ll evaluate the situation on its merits and probably say yes.
ELKIE: In an expanding global economy are you limiting what you offer geographically?
NICK: No, we’ll go almost anywhere, as we operate an agreed fix fee, which is database size driven. Any costs can be factored in right at the start. Also the other elements of our group support live applications for global organizations so it’s not really an issue.