Data Management

Does your system still contain irrelevant records from the year 2000? What is the plan for archiving those records? What’s the technical approach? Will users need to access archived records? If you’re purging records, how will you identify records that need to be purged and do the purge without changing “good” data?

Purging/archiving old data can be critical. For one client, we found more aged records than current records!

Does your system have duplicated records—for example, two slightly different names that actually refer to the same person? Or do you have records with data in the wrong format (for example, a zip code like “B894A”)?

Is your system’s database structure compatible with the structures of other systems with which you must exchange data? Maybe your system stores data that the other doesn’t–and vice versa. Or do you store the same information—but in fields that are named differently in each database?

Are you required to use specified formats (such as NIEM, National Information Exchange Model) for your system data? Government agencies often must use that format (or others) so that agency systems have effective data exchange.

Auctor brings a thorough understanding of challenges that are unique to government agencies with legacy systems:

• Validation. Legacy systems often do not have robust data validation. A legacy system may have lots of irregular data.
• But modern systems often have automated validation plus database structures that enforce it. “Bad” data may be mixed with “good” data. Are you prepared for these additional challenges?
• Single-instance storage. Does your system store multiple instances of, say, a person’s demographic information? Modern systems aim to store only a single instance of a person’s demographic (or other) information. You will want to deduplicate data in your existing system before you move that data to the new system.