There is method to our
data migrations

Our unique methodology turns your BAs into programmers by allowing them to record the conversion’s business logic in a 4GL language, which DCA automatically turns into source code.

This allows the number of key personnel responsible for the development of a source code module to be reduced. It also allows programmers to focus on the input/output (I/O) aspects of the conversion (or the Extract and Load portions of an ETL project), which reuse system-specific I/O APIs whenever it is convenient.

This segregation of responsibility reduces the needs for programmers and drives down the costs.

Making data visible as early as possible is key to a successful conversion. By performing data analysis and auditing in the early stage of the process, the BAs use reporting features and rules to create code that highlights data anomalies or unexpected characteristics.

Data cleansing can start immediately afterwards. Data can be “fixed” in the legacy system or as part of the data translation, and the conversion maps and associated code modules can use the information to correctly handle all data permutations the first time.

Understanding how the legacy source system differs from historical documentation and correcting errors at the source the first time dramatically reduces risks, drives down costs and shortens timelines.

Finally, our methodology results in the automatic creation of documentation. At the end of a project, all business rules are encapsulated in a set of “datamaps”, each of which handles the conversion of a subset of business data and is written in a 4GL language that nonprogrammers can read (and create).

Since the datamaps are used to automatically create code modules, they are invaluable for design and code walkthroughs, as well as post-project documentation.