FAQ / Articles - Why DataLynx?
Why DataLynx?
Because Datalynx can save you money, save you time and ensure accuracy.
There are three standard approaches to data migration:
Each of these approaches has a cost and personnel structure. We can consider how the use of each approach compares with using DataLynx.
With in-house development costs are often under-estimated. Invariably the initial staff requirement projections prove to be inadequate. It's often considered that just a couple of programmers would be sufficient, however even a small data migration will usually require a technical team including:
- Project Manager
- Data Analyst
- Programmers
- Testers
Quite often these people are recruited on expensive short-term contracts, incurring recruitment and possibly training costs. Add to this the associated cost of the desk space, holiday pay, sick pay and all the other costs of employing people and you will find the in-house approach can be a high cost solution.
There are, of course, advantages of using the in-house development approach. It may be possible to utilise existing staff members who are likely to be familiar with your company's data. They can tailor a solution that can be modified for performance or other specific requirements.
However, using existing IT to migrate data is not always the best use of its time. Migrating data is a once-only problem. There are likely to be many other, on-going, competing projects. It is better for your staff to be working on long-term concerns than on one-off problems that offer no reuse.
Existing staff will almost certainly implement a solution using their current skills, regardless of whether that is the most efficient way to migrate data.
Data migration will be on the critical path of the project. Using inexperienced staff to cut code manually is slow and prone to errors. They are likely to run into typical problems resulting in project overruns and possible risk of failure.
DataLynx know the common pitfalls and, more importantly, how to avoid them. Our staff are experienced data migration consultants armed with powerful ETL software.
We do not have to write software from scratch. Using the Lynx ETL software we can eliminate the need to laboriously develop and debug code that has a limited lifetime. Our Lynx ETL software automatically writes optimised C++ programs using tested, proven algorithms tailored to your needs.
Saving you time. money and ensuring accuracy.
Another common method of migrating data is to purchase ETL software. This is software which eliminates the need to develop bespoke programs. After suitable analysis of your data and careful configuration ETL tools can perform a data migration.
ETL tools offer a number of benefits over the in-house development approach. They avoid the need to hand code any software, and significantly reduce testing times.
However, ETL tools are expensive to buy, difficult to use and likely to incur unforeseen support costs. Selection of ETL software can be time-consuming and therefore expensive. It's usually necessary for staff to attend training courses before they can use the software and there may be a lengthy learning curve before any productivity gains are made.
Although ETL tools can reduce the cost of migrating data by eliminating the need for development programmers there remains a need for at least one data analyst who will need to be trained to use the ETL software, as well as project management and testing personnel.
There remains the risk of the inexperienced data migration team falling prey to common and avoidable problems. Although these are often quicker and cheaper to circumvent using ETL software there remains a risk of project overrun, leaving data migration as the stumbling block in your critical path.
These drawbacks can be avoided by using DataLynx. We have experienced consultants and provide free ETL software tools.
This is often seen as a cheap, risk free option when migrating data between systems. The perception is that an operator can quickly and easily apply required changes with no expensive software, no development programmers and no endless testing loops.
But for anything other than the smallest data migration, this is probably the slowest, most expensive way of transferring data from one platform to another. And the least accurate.
The only way to avoid human error is to constantly check and recheck and even then it is almost certain that a significant number of errors will go undetected. The quality of the data in the new system will be questionable, leading to operational delays and failures.
In fact, unless the volume of data being transferred is very small this is simply the worst possible way to migrate data.