Data Migration

Stelo is designed to make all deployment steps easy and straight forward with many automatic and automated procedures. You can choose which tables, rows, and columns you want to replicate, ensuring that data is replicated efficiently from one datatype to another without complex programing. A typical deployment has you up-and-running in hours, not days.

This is a key area where you can separate the wheat from the chaff. The best replication solutions deploy in under 24 hours. The worst require a week or more of configuration. Deployment time is also a good way to assess reliability. If the initial configuration is complex and time consuming, you can expect stability and performance problems to arise in the future.

Baseline copies of data should not require more than 24 hours to create unless you are replicating an unusually large amount of data. If initial customizations take a lot of time upfront, you can expect similar lags when customizing in the future as well. High-performance software does not require much tweaking, and you should be wary of the reliability and accuracy of solutions that require extensive reprogramming

Stelo gives you greater control by allowing you to choose replication of the data you want with both vertical and selected horizontal partitioning. Replace existing tables or merge on a row-by-row basis. Stelo also supports derived destination columns and data transformations, including automatic and customized conversion and selection of dates, views, indexes, and constraints. While flexible, Stelo fully enforces the enterprise security mechanisms by integrating with both SQL Server/Windows security and the native security of your Db2 system.

We encourage customers to configure Stelo’s software to create the destination tables on the SQL Server. In part, this is to ensure the proper mapping of change data captured on the IBM i system and the destination table. Also, if your high availability (HA) software utilizes *AFTER images only for capturing change data, then Stelo’s software must rely upon a synthetic column (the Relative Record Number or "RRN") to uniquely identify the row in the destination table, and it is unlikely that the Oracle JD Edwards (JDE) tool would provide this column. Therefore, it is best to allow Stelo to create the destination, including this column for each table. Alternatively, if the HA software configures *BOTH images in the journals then we can dispense with the RRN column and just utilize any unique index (including a primary key) to identify rows.

Another issue that should be addressed in the planning stage is the use of Unicode datatypes on the destination SQL Server. We strongly encourage customers to use NCHAR/NVARCHAR data types for SQL Server, as this provides the greatest fidelity when mapping data from IBM i EBCDIC to Windows and other non-EBCDIC environments. Our recommendation is to allow Stelo to create the tables and exploit UNICODE data types, and then use the tool to create any additional indexes.

Stelo offers simple installation and GUI-based replication. Our user-friendly, browser-based GUI does not require a programming background to set up or operate. The easy-to-use interface comes standard across all Stelo solutions for snapshot, incremental, and bi-directional replication. Once running, Stelo reliably operates in the background without needing dedicated engineering support to maintain and manage.