[00:00:01] Speaker A: What to do with old data. A follow up to zombie Systems episode.
Hello. Thank you for joining us. This is what counts. A podcast created by Trailblazer Consulting. Here we highlight proven solutions developed through our experience working with companies across various industries. We talk about how you can apply these solutions to your company. We share our experience solving information management challenges, like creating and implementing a records retention schedule, creating an asset data hierarchy, or helping with email management. This is Lee, and in this episode, Moore and I will talk about if you have to leave the data behind, these are the things you should think about.
[00:00:39] Speaker B: All right, sounds good. I was trying to think of a zombie system joke, like, should we call this the Walking Dead data or something?
But I decided that wasn't funny, and you thought so, too.
So we talked last time about, or in the zombie system episode, we talked about how when you're trying to set up a new system and you want to migrate data into the new system, often the project team really only wants to migrate active data. They don't want to think about data that's older or old.
But from a records perspective, one of the key things that's always true around records is that we think about the whole lifecycle of the information. When it's created, when it goes into its retention kind of inactive period, how long do you have to keep it, and what happens to it at the end? So data that gets abandoned in a zombie system, you can't just let it sit there. You used to be able to just let it sit there when it was paper. It was easy to let it sit there as long as you didn't burn it up. It was pretty much going to be there when you went back to look for it. But with electronic information, the system upgrade cycle is 18 months or less. Now. Hardware upgrade is one to three years. You can't just assume that electronic data is going to be there when you want it.
Second problem, you can't just assume that it's going to go away if you don't actively do something with it. So you've got to pay attention to it. All right, decision's been made. You're not going to migrate everything into the new active system.
What do you have to think about now? So first, what kind of data are we talking about from a records perspective? What record category does it fit into? It's nice when it only fits into one, because then you only have one set of retention triggers and retention periods and other requirements to deal with. But a lot of systems have more than one record category represented, especially like an enterprise resource planning system. It often will have AP AR, it might have payroll, it might have revenue like some project data, and revenue data might have payroll data. You have a lot of different pieces of data that have different triggers and different retention periods. You might have to break it down.
You might not be able to break it down, but we'll come to that in a minute. So the first thing is the record category. The second thing is how old is this data? And for each record category, what would be the normal remaining retention on it? So if the records have an end of fiscal year trigger to go to inactive and start the retention period, and we're talking like it's a two year ago set of data, maybe it's from the end of fiscal year 2022 and it has a ten year or a 15 year retention, then you're looking at 2037 potentially for keeping this data alive, accessible, and able to be produced if needed. But it doesn't have to necessarily be active every day.
Okay, what format is the data in? Because format is going to lead you to your options.
Can you write the data out of the database into a flat file, or into a spreadsheet, or into reports, for instance?
Thinking about training materials. Can you create a PDF or, or a PowerPoint version of a PDF or something that captures the training course materials so that they're unalterable and you can keep them for the right amount of time? Can you print out a report of the attendees that were in any given class with the date and the type of the name of the class and who was there, and keep that as a PDF document so that you can store that. PDF's were specifically designed to last independently and for a long time. It's the portable document format for a reason. It can be read with a free reader, and it doesn't go through a lot of cycles of upgrading on the reader side of it. So if you can get something to be a static report or a static document like that, a PDF is a good choice. But what if we're talking about a transactional system? It's a trading system or it's a financial system, and a PDF is just not going to give you anything that you need.
The challenge there is how you maintain the transactions so that you have the inputs and the outputs going in the right order. It's not just a table, a relational database with tables and relationships. You've got to have the transactions. So do you have to keep the old system alive in case you need to query it?
Some big systems like SAP and Oracle financial, some of those systems have an archiving function where you're able to extract a whole set of transactions and sort of keep them contained so that you don't lose the in and out the order of things. And it doesn't change the outcomes, it doesn't change the reports. If you wanted to rerun a report, but if you have a smaller system that doesn't have that sophisticated functionality, your options are more limited. And you may need to keep that system alive for a time. Or you may need to. Maybe you can pipe the key data into like a SQL server database or an access database or something that recreates the structure and allows you to at least query it if you need to. Obviously you need to involve it in those decisions to decide to determine what's feasible. And are you getting to be where the creating the thing that you want to be able to query is actually more expensive than keeping the old system alive for a certain amount of time?
Those are the record side of the choices that you need to make. One last piece of one last thing to consider is whether anything in your data set is on legal hold. Because even if you've met the retention period, if it's on legal hold, you can't destroy it. You have to keep it alive and you have to keep it accessible in case you have to produce it as part of whatever action caused the legal hold.
This is a reason to have your legal hold process be in good shape so that when the legal hold is over, you release things from the legal hold so that you know that you can destroy them when they hit their retention period.
But otherwise you have to go ask that question every time. Are we ready to destroy this? Are we ready to destroy this?
So those are the considerations to keep in mind is record category, age, retention period format. What kind of options do you have? If you can get to a static state where a report or a PDF, something that can be printed out to a PDF that basically looks like a document, then that's ideal. It's the easiest thing to save.
And then whatever you do, document everything. The whole process needs to be documented. This is how we made the decisions. Again, you get the approval of all the involved stakeholders and supervisors and managers, whoever is responsible for this business function and these records that are contained in this database.
You might also look to see if there are other sources for this information. For instance, all of your financial transactional data supports your income tax returns or your various tax returns, sales and use tax, operational tax, income tax, all of those different tax forms. If you're a publicly traded company. It supports your 10K filings and other SEC filings. So if you have submitted everything, everything's been audited and your audit period is passed, saving the transactions may become less important. But your records retention schedule has probably been built around, what are those audit timeframes to make sure that you are keeping things long enough in case an audit begins. So the world of electronic information offers a lot of flexibility and a lot of options, but it also gives you a lot of responsibility in terms of how to maintain, how to meet your legal requirements, your obligations to your data. And these are just a few of the things to think about.
[00:09:03] Speaker A: The thing I kept coming to my mind Washington.
There are many it folks out there that don't really want to hear from an IG person, and that's because they would rather just delete and get rid of. And from a compliance perspective, it's not that easy.
[00:09:23] Speaker B: Yes, that is true. And when they come to you, when the IT department comes to you and says, give us permission to throw this stuff away, and you say, no, they hate that.
But this is another good reason for partnering with the IT team early on, because there are some of the drivers around. Don't move old data into the new system because it slows the project down and the data might not be as clean as the new data is going to be, or the structure might be different and it just wants to move forward and get the new project done. But once they understand the implications, maybe they'll be more likely to help with, okay, we should migrate this. The other thing that might come out around this whole process is we've already streamlined records retention in a lot of ways. If you think back dating myself all the way back to the 20th century, when I first learned the word retention schedule, everything was in paper folders, and you wanted to be as granular as possible. The first retention schedule I ever looked at was for the US Environmental Protection Agency, and it had 750 record categories.
The armed services, at the time, the army of the Air Force, they had well over 1000 record categories. Today, when we create a retention schedule, we're aiming for under 100. And there are some organizations that have gone even farther to the big bucket theory of having fewer than 20 categories. And the reasoning for all of that is that electronic information is more accessible. You don't need file folder labels to help you find things. You have a lot of other data points. That's true.
We try. The reason we always aim for 100 ish is because we're trying to balance keeping things not too long, but long enough to meet all the regulatory, all the operational and regulatory and legal requirements.
We don't want to keep records that could be destroyed three years. We don't want to keep them for ten years if we can get rid of them. But sometimes the process of figuring out how do we migrate from system to system?
You get asked, we get asked to look back at the categories and say, can we make these? Can we make these more reasonable? Reasonable is the word that non records managers use when they ask the question.
But basically, can we rationalize these to have fewer categories? Maybe it's less time that needs to be saved. Maybe it's just fewer records that need to be saved.
Instead of going with a just keep it all, because it's harder to pick things out, which is true. We take an approach of everything that has to do with this process, just keep it, instead of picking out the one document or the one record, the one row in the database. But these are choices that you get to make. You get to, it's an opportunity because you want to make the process work better. You want your system to work better, and you want to be sure that your company is keeping the records that it needs to have in order to operate and demonstrate compliance, protect your legal and financial responsibilities and rights and interests of you and your customers and your other stakeholders. Those are the key guiding principles to make sure you're doing those things and then figure out the best way to make the details work. So a migration of a system is an opportunity to look at those choices.
[00:13:05] Speaker A: Again, I think your tolerance of risk is thrown in there as well.
[00:13:12] Speaker B: Absolutely. Yes.
[00:13:14] Speaker A: The company's tolerance of risk, right?
[00:13:15] Speaker B: The company's tolerance, yeah. Understanding your risk. And then what's your tolerance for? It is definitely part of this. And we've certainly had clients who said, yeah, that's not going to happen, and I'm not worried about it. So get rid of those records and that's their choice. Ultimately, that's your choice. But make that an informed decision, not just an offhand, I don't care, I don't feel like it kind of decision.
[00:13:39] Speaker A: So yes, that was good.
If you have any questions, please send us an email at
[email protected] or look us up on the web at www.trailblazer.us.com. Thank you for listening and please tune into our next episode. Also, if you like this episode, please be a champion and share it with people in your social media network. As always, we appreciate you, the listeners. Special thanks goes to Jason Blake who created our music.
[00:14:08] Speaker B: Thanks, everyone. Thanks, Lee.
