Go Back
On-demand

The Great Migration: Do’s and Don’ts of large data migrations

Whether migrating from on-premise solutions to the cloud or end-of-life solutions, the great migration can be very scary. And with good reason! There’s lots of data and lots of risk.

Unique circumstances require specific customizations from vendors. But what are the do’s and don’ts in every migration? Our experts have seen it all and they’re here to help your team preserve what works and move through a painless migration.

Watch now to explore:  

  • Understanding the need for migrating from legacy systems to modern cloud-based platforms.

  • Practical strategies for planning and executing a successful data migration process, including key stages and considerations.

  • Insights into popular cloud storage options and best practices for ensuring a legally defensible migration.

  • Tips for maintaining metadata consistency, integrating diverse digital communication types, and ensuring platform compatibility with modern channels.

Speakers

Anthony Diana

Partner, Reed Smith

Simon Altit

Director EMEA, Insentra

Alex de Lucena

Director of Product Strategy, Shield

Tom Rimmer

Migration Expert, Shield

  • Transcript

    The Great Migration: Do’s and Don’ts of Large Data Migrations

    Shield Insiders In-Focus
    Speakers

    • Alex DeLucena, Director of Product Strategy, Shield (Moderator)
    • Simon Altit, Director of EMEA, Incentra
    • Tom Rimmer, Regional Sales Manager, Shield
    • Anthony Diana, Partner, Emerging Technologies & Bank Tech Group, Reed Smith

     

    Introductions

    Alex: We have a really great panel of specialists to take us on this journey. I’ll be moderating — I’m Alex DeLucena, Shield’s Director of Product Strategy. I’m going to pick on each of you: Simon, Tom, then Anthony. Tell us who you are and why you’re here.
    Simon: Simon Ostit. I’m the Director of EMEA at Incentra, and I’ve been in the archive and migration space for the best part of fifteen years. I’ve either delivered, led, or sold a little over five hundred projects in this space.
    Tom: Hi, everyone. My name is Tom Rimmer. I’m a Regional Sales Manager at Shield. I’ve had the pleasure of dealing with these types of projects — I think the earliest one was 2003. So I’ve seen a lot of clients and prospects go through the challenges of change, and hopefully I can bring you some of the stories we’ve seen and some of the challenges we’ve had to address.
    Anthony: Hi, Anthony Diana. I’m a Partner here at Reed Smith, part of our Emerging Technologies and Bank Tech group. I’ve been working with data migrations — actually, messaging archives — for probably about twenty years, and I’ve done dozens of migrations, usually focused on the legal and regulatory issues associated with them.

    The Fear of Migration

    Alex: Let’s start with an imagined exercise. When firms imagine moving to a new archive, it makes intuitive sense — like moving from one house to another. The old house hasn’t kept up, it’s harder to maintain, it doesn’t accommodate new technology. That makes sense. But migration is a different, related animal. That’s where everything in the basement of the old house — all the old exercise equipment and kids’ toys — has to move into the new house, and it has to make sense. We have to know where everything is, no matter how old it is. When I articulate it that way, I start to feel tangible fear; I don’t want to do it. So many organizations choose not to, or kick the can down the road, or maintain two or three archives. Tom, as someone who’s convinced people to migrate, let’s start with you: what is that fear, and what drives it?
    Tom: You’re right, Alex. Going back to your house analogy — you see the new house, you like it, and the new technology’s benefits are straightforward. But then you think about that old house: how do I move your valuable jewelry, your valuable data? What’s the risk if you lose some of that? What’s the risk of data leakage? For most organizations, it’s their crown jewels — how do they protect it, move it safely and securely, and make sure that when they take it to the new environment, it still delivers the outcomes they want? If you’re moving from one archive to another, you still need to be able to discover and find that information. And the other side is: who else needs to be involved in these projects? It’s not just the concern about the data — it’s which groups within my organization need to see the processes and the preparation.
    Alex: And Anthony, there has to be a regulatory component that holds people up too. Why is that such a source of fear?
    Anthony: People are always afraid of stuff they don’t understand. A lot of legal and compliance folks brought in to say “we want to do this migration” don’t know enough to say what the risks are that they have to mitigate, or what the steps are — often because people don’t explain it to them. When you explain what the risks are and the steps you’re taking to mitigate them, they get comfortable, but someone has to be there to explain. What usually happens, bluntly, is that legal and compliance aren’t paying attention, or they’re told after the fact and then asked to sign off — and they think, “What am I signing off on?” That’s one of the challenges for the industry as a whole: getting people to understand what the risks are. Some of these risks are accepted, in a lot of ways, with these migrations — error rates and things like that.
    Alex: Simon, anything else to add on that level of fear that holds organizations back?
    Simon: A couple of big ones. They know they need to do something, but their platform is aging and they’re fearful that even touching it — extracting large volumes of data — is going to bring it down. Ultimately, a lot of the time they do nothing, because they think it’s easier just to keep the lights on than to risk hitting the storage too hard to pull that data out. It’s very “devil you know.” The other big one everybody is fearful of is time. A big driver around these programs is the total cost of ownership of getting out of the existing platform and into the new one, and probably the second question every customer asks is, “How long is it going to take?” They’re fearful it won’t get done in a timeline that helps them hit their investment timelines.

    Three Kinds of Organizations

    Alex: As a framing mechanism, I think of three kinds of organizations when it comes to migration. First, the brave — the people embracing transformation and new technology. They’ve done their homework and they’re ready to migrate for all these brave reasons, because it is brave to take this leap. On the other side, you have the desperate — people in end-of-life scenarios, paying for support, their platform doesn’t work, a regulator wants something their platform can’t do. They’re moving, but under constrained circumstances, awful timelines, paying money they hadn’t budgeted. Those are the people who usually move. And in the middle, everyone else — waiting, not sure, sitting on this data. Let’s move through each. I want to start with the desperate. Simon, when we think about the need for change, how does legacy technology drive the desperate?
    Simon: Legacy platforms don’t store much more than mail and, occasionally, a bit of instant message. But with the amount of regulatory and compliance requirements hitting most businesses now, and the need to retain vast amounts of disparate data, they just don’t have the capability to consolidate all that information in a single place that’s easy to access and search. That drives the need to get off what they’re on. The other big one is aging infrastructure — large CapEx investments they’ve been sweating for a long time, and it’s now at the point where they can’t continue to sweat it. The cost of maintenance is forcing their hand. It’s not that they want to do it — they have to, because if they don’t, they’ll fall out of their internal compliance requirements around being a stable system.
    Alex: Tom, would an on-premise archive lead to any sense of desperation?
    Tom: Simon touched on it. In more and more discussions with clients and prospects, they’ve sweated those assets, they need to change, and they’re seeing end-of-life statements from some legacy platforms. A lot of them have a strategy to move to the cloud — they want the benefits and modern capabilities. But I’d flip one side of that: it’s not just on-prem. We’re seeing some legacy cloud vendors too, with their own private, proprietary clouds, where clients are held hostage — export costs, exit costs. So you’ve got on-prem driving the need to change, but also these legacy cloud platforms.
    Alex: The hostage costs are a great example, because you’re trying to sell something internally knowing the cost is going up just to get your data out, and where’s the benefit? Another one I’ve seen is data integrity — people needing to be comfortable that everything coming in can be accounted for, reconciled, and played back. When it was all EML coming in, legacy systems could say “99.9% is here.” But now you’re getting a Slack feed from a third party, and they don’t have the tooling to provide that overview. Anthony, how do regulatory pressures drive the desperate?
    Anthony: A number of things. Number one — no one likes to hear this, but the SEC and FINRA have been pretty open that they view any costs associated with record keeping, archiving, and surveillance as the cost of doing business. So you don’t get any sympathy by saying “it’s really expensive.” Second, regulators are looking more and more at different data sources they think should be archived and surveilled. FINRA just came out last week with a clarification that if your customers are using artificial intelligence with your applications, that’s an electronic communication that has to be captured — which makes sense, because you may be getting investment advice from an AI tool. That’s the tip of the iceberg. What worries me is that as regulators think about collaboration tools like Zoom and Teams meetings, they haven’t really said what will need to be captured. And a lot of these legacy archives were built for email; none of this stuff is email, so you’re transforming it and putting it in the archive, and that’s a data-integrity risk. You don’t want to be in a situation where a regulator says, “What is this gibberish you just produced?” and your answer is “we just shoved it in there.” That’s not an answer.
    The other thing regulators, particularly on the privacy side, are focused on is deleting data you don’t need. A lot of legacy systems don’t have good functionality for routinely deleting messaging data — you have to apply retention, apply legal holds. It’s only a matter of time before regulators notice how much data is just sitting there historically with no need for it. All of that is risk — litigation risk, privacy risk — with no business benefit. You’re paying for storage of data that is just risk.
    Alex: A dirty secret is that a lot of organizations in the last ten years lifted their deletion as a risk mitigant, because storage was relatively cheap. Now, as volumes increase, that equation’s changed, and they’re faced with an end-of-life where they have to move it. For anyone listening, pop questions in the Zoom chat and we’ll address them in flow or at the end.

    The Brave: Cloud, SaaS, and Transformation

    Alex: Let’s talk about the brave — people making these moves preemptively. Tom, you touched on SaaS and the cloud; let’s start there.
    Tom: The new technology out there is flexible and the performance is there. When clients are doing discovery over five or six people in legacy systems, it might take over twenty-four hours to get results back. With the latest technology, over billions of records, you can get immediate results — and if they come back quicker, you can address them quicker. There are more tools to reduce the amount you’re exporting to a regulator or for litigation. So the brave accept that, see the benefits and cost drivers. A lot of the conversation is about time to value — how can we get to that value quickest? — and they see cloud as a great way to get up and running quickly, and to support all the varied content types coming in, in their native format rather than wrapping everything as an email.
    Alex: Anthony, what would you add? You’ve helped a lot of clients on their cloud journeys.
    Anthony: For most sophisticated IT personnel, the plan is to put everything in the cloud — that’s where the world is heading. Ten years ago, financial institutions were very hesitant, but once they got comfortable, they saw the advantages. Most IT departments are focused on innovation and productivity, and the best place to capture that is the cloud, because adoption of innovation — whether it’s AI or whatever — is so much quicker there. There’s still lots of risk associated with it, but that’s a given now, along with the cost savings people believe will happen.
    Alex: One thing I used to point out when I was on the compliance side is how much we already live in the cloud. Our teams were in the cloud, our consumer experience — we put our kids’ pictures in the cloud. So what are we really resisting? The brave are often organizations who recognize that, and who have these digital-transformation roles now — people charged with not just getting an organization onto a cloud, but cleaning up all the wires under the desk and getting the organization to a future-forward place. Simon, another thing that comes up is firms developing AWS- or Azure-specific strategies.
    Simon: The big one is that a lot of the drive for cloud — rebaselining what they’re doing in the data center — is forcing them off their older platforms. When they do the cost modeling and realize the level of pain of moving like-for-like, that’s the driver, especially with a cloud-first strategy. I’d take a slightly different view from the rest of the panel: I think it’s less about a cloud-first strategy and more about an as-a-service strategy. They want to get rid of the ongoing administrative overhead and the knowledge and skill set required to maintain these platforms. That’s what the investment in AWS, Azure, and the like allows them to do — someone else takes care of the more difficult components, so they can consume the tools they want as a service.

    The Middle: What to Do With Old Data

    Alex: Let’s move to the middle — someone who could, should, and is open to migrating, but isn’t. Anthony, if they’re not migrating yet, what are they doing with those old archives?
    Anthony: The business case is often easier to say, “For all new data, we’re going to use that new archive and take advantage of the cloud.” I won’t say it’s the easy sell, but it’s the easy sell. The harder sell is: what do we do with the old stuff? Some people have data sitting there twenty years, ten years, because they haven’t been deleting. Most people don’t even know what’s in the archive going back that far — there were often other migrations or acquisitions, and they just shoved data in, so it’s not necessarily clean. A lot of people say, “I’ll let it die on the vine — we’ll apply retention and legal holds and delete it.” But because they haven’t been doing that, it’s a lot of work; it’s not as passive as they think. You still have to analyze what’s there, whether it’s on legal hold, all the identity issues, the aliases. So even though people say they’ll let it die on the vine, what I generally see is it’s not dying on the vine — it’s just literally dying. The technology dies, but the data isn’t gone, because they haven’t done the work to delete it. Making a decision not to do something is making a decision to keep it. There’s no such thing as dying on the vine — there will always be legal holds. So you should always consider that leaving it isn’t really an option; you’re going to have to migrate it eventually.

    Building a Migration Plan

    Alex: So let’s help these people out. What’s the first component of a good migration? I think it’s having a plan — which sounds simple, but it’s a complicated plan. Tom, what does that look like?
    Tom: Preparation is key. Everyone thinks the technology takes time to bring the data over, but the technology’s moved on — the speed you can migrate is a lot quicker now. Putting the time and effort into the upfront preparation and planning is key: bringing in the experts who’ve done this, who know your data and channels. Understand the legacy platform — where is your data, your data mapping, what data sources came in? Understand the environment you’ve got at the start, and the outcomes you want to see in the new environment, because as you move that data over, will it act and represent the same way? And understand which groups within your organization will be involved, and bring them in early. On one project, IT drove the migration, but what slowed them down was making sure security and the records management team came along on that ride, because they had to do their own due diligence. So early on, make sure you’ve got those subject matter experts along for the ride.
    Alex: Anthony, you zeroed in on legal hold and data deletion. What does that conversation with legal look like as you’re planning?
    Anthony: It’s setting expectations about what decisions you expect legal and compliance to make during the migration. Ultimately, someone’s going to have to sign off and say, “You’re decommissioning this legacy archive” — could be billions of messages — and putting your name on that signature is always one of the hardest things to do, so you have to prepare them that that’s the ask. Second, everything has to be documented — the regulators want this. There are lots of decisions along the way besides decommissioning: error rates, for instance. Coming out of billions of messages, not every one will migrate correctly — there are always errors, and legal doesn’t always understand that’s standard. The key is legal and compliance have to agree that whatever errors there are are really errors, and they’re comfortable with them. We document that in a solutions-design document upfront: here are our expected errors. Often these migrations show how bad the legacy archive is, because a lot of it’s corrupt — and you weren’t getting it out of the old archive either. Regulators want the documentation: the chain of custody report, the error report, the reconciliation from every message. All of that gets you to the high-level decision of getting rid of the legacy archive.
    Alex: And you can POC any of that. If there are things they need to see to be comfortable, those are all things you can test and validate. Simon, any phases in the planning we’ve left out?
    Simon: A couple. First, what was the use case the original platform was put in place for, how was it architected, and how is it being used today — versus how are you planning to use the new platform tomorrow? A big part of the transition is making sure the data makes it over in a way that’s easy to consume in a similar fashion, and often the old use cases don’t align with how use cases work today. The difference between success and failure comes down to user experience — you need the user at the center of that journey; the data is what’s important, but it’s the way you engage with the data that matters. The other big piece: these platforms have existed for twenty or thirty years, so in all likelihood the platform the customer is in today isn’t the first — they came from another platform and did migrations back when the supporting technology was less mature. So there’s a raft of additional issues with data that’s already been migrated once and potentially converted. Understanding that upfront lets you plan for it and put it in front of people like Anthony and his team.

    Reconciliation and “No Such Thing as Lift and Shift”

    Alex: Simon, what does good reconciliation look like?
    Simon: We look at it in a couple of phases. First, look directly at the source platform and get an inventory of what’s in there on its own, without any third-party tooling — what can you actually see from the platform itself? Second, the migration tooling interrogates all that data, making sure what you can see directly in the platform aligns to what the migration tooling has discovered. Third, once you’ve moved the data to the new platform, confirm that what the migration tooling reported is what’s actually arrived in the target. You’ve got to do all three so you can be certain you have consistency across the motion. The better products give you unique identifiers that fit across that entire motion, so you can track an item all the way from the source into your new platform. That’s the chain of custody and data lineage we’re talking about.
    Alex: The words that always freak me out are “it’s just a lift and shift.”
    Anthony: There’s no such thing as a lift and shift — everyone loves to say it. One of the reasons is testing and validation. Once data lands, someone has to test and validate. You’ve got to get your stakeholders — legal, compliance, surveillance — to understand the use cases so they can test whether their use cases still work, and feel comfortable the tool works. It’s rare that I have a migration where the testing doesn’t surface some anomaly, particularly with older data. You have to investigate it. This goes to your timing point: moving the data is the easy part now — it’s the testing, validation, and dealing with anomalies that takes a long time. The last thing you want is to skip the POC, migrate everything, and then realize it was done wrong and have to do it again. Two to three months of planning, testing, and POC upfront makes a huge difference. Part of reconciliation matters here: your discovery team will do a search in the old legacy archive and the same search in the new one and expect the numbers to match. They often don’t, because of errors or other issues — and if you don’t have that reconciliation, legal will say something’s wrong and won’t sign off. With reconciliation, they have evidence to point to, because at the end of the day it’s attestation and sign-off.
    Alex: And be aware of PMs — and vendors — who say “this will all be done in three months.” A good vendor understands these steps, understands it’s complex and takes time, and helps you document and see through each stage.

    Aligning Stakeholders

    Alex: Tom, how do you get all these different stakeholders aligned and informed throughout the project when they’re often siloed?
    Tom: The first thing is to identify them — who’s going to get involved, all the different departments — and make sure everyone comes together early. Get their ownership: “You need to help me and be accountable here.” Make sure they’re aligned and bought in early, and that they all know their gate to sign off, and that nothing’s going to be perfect. How do we partner to get over these challenges? It’s that visibility, examples, and working as a partner. Communication is the key — communicating all the time.
    Alex: And there’s always an outside counsel with an AOL address who has a ton of influence on the whole project — you want to find them early and get them across the whole thing.

    AI and the Future of Archives

    Alex: It’s 2024, so I’d be remiss not to ask about AI. Simon, how do you see AI impacting migrations, at any stage?
    Simon: At the moment, it’s not something that’s really hit our radar from a requirements perspective. But we’re hearing a lot about people looking to start archiving prompts and storing that long-term. So it’s coming, but whether there’s a clear path forward today is still a bit of the unknown. There are some workarounds a bit of engineering can do to get some of that data stored, but it’s still early days — the technology is moving faster than the supporting technology can keep up.
    Alex: The example I’ve seen is how we drive better insights across that data. People often don’t have a lot of insight into what’s actually in the archive — trends over time — because the function is so focused on day-to-day ingestion. And there’s a potential for newer archives to have a more forward-footed approach to AI, and partnership opportunities. One annoying thing about AI right now is the noise, but one of the cool things is the opportunity to partner — vendors have the tool sets and know-how, and customers have the need and understand the use cases. Anthony, what future trends do you see influencing data migration strategies in the next three to five years?
    Anthony: One thing we’re seeing already — I’ve seen charts from clients who’ve analyzed the data going into these archives — is that for the first time in twenty-five years, the amount of email is starting to go down. Meanwhile, things like Teams and Bloomberg are exploding. So what’s in the archive is going to be very different in the next five years. It’s no longer just an email archive; it’s a messaging archive, with a lot of different data points — which is why identity management is one of the most important things in these archives. The other trend: almost every application out there — trading applications, contract management — now has chat functions, and whether that has to be captured is something legal and compliance have to work out with FINRA, the SEC, and the like. If it does, it’s all different types of data going in, and you have to validate that all of it migrated correctly. Email may be easy, but a lot of migration tools may not be as good with the others.
    It’s so hard to model what the future looks like in the next five years when you’re doing a contract, because no one knows data volumes or types. All we need is one ruling from the SEC or FINRA that says, “Because everyone’s doing Zoom and Teams meetings, now you have to capture them” — they know it can be done — and that would be devastating. Good for the vendors because of storage costs, but awful for everyone else. And one concern I have when all these new things happen is that the legacy archive sitting there to migrate gets neglected, because no one has time for it. It literally dies, and no one knows anything about it except the regulators when they have an investigation and want to go back that far.
    Alex: That already happens today. No one knows anything about it; it’s sitting there, and it’s bad.

    Contracts: Don’t Get Your Data Held Hostage

    Alex: One quick thing you touched on, Anthony, was user experience — for the end users of the archive and the people using the migration tools, the user experience is primary, especially as you bring in new channels and people’s ability to visualize and interrogate data points they couldn’t in their legacy archive. Tom, what’s some fine print that can be a sticking point around support and end of life with the existing archive?
    Tom: The challenge with legacy systems and vendors is the handcuffs. There are contracts with large export fees to pull your data out. Vendors need to change, because change is continuous — what’s great now, in five years there will be a new tool. So vendors like us need to make it simple: it shouldn’t lock you in or handcuff the client’s data — it’s their data. A lot of existing contracts have these handcuffs and controls. One thing we put into our contracts is that the data is your data; if you want it out at the end, there’s no cost. That’s really important for people to look at as they go into a migration and their next vendor: how much control do I have over accessing my own data? And support is a key one too.

    A Success Story

    Alex: Simon, tell us about a success story you were able to help with.
    Simon: One we collaborated with Reed Smith on not that long ago, for a global investment bank. One decision made collectively early on was to bring both their outside counsel and their auditors in right from the get-go. That set us up because there were clearly defined roles and responsibilities, and we’d mapped out how to meet what were, at times, quite challenging demands for information from both counsel and the auditors. Had we not done that upfront, we probably would have spent a year at the end of the program just trying to produce all the necessary reporting. Another big part was very clearly defined use cases — both from a user-experience perspective, because there was end-user-facing data they needed to maintain access to, and because there were three or four categories of data that needed to move to different platforms, packaged in different ways with appropriate supporting reporting. That meant we nailed it early enough to push data at a rapid pace. There was a week-long period where we pushed just shy of ninety terabytes to the cloud, which is somewhat unheard of coming out of legacy archive platforms. Our measure of success is: if it’s readable and accessible in the source platform and supported by the target platform, we should be able to migrate it — and the numbers we hit were like 99.999-something percent. Unheard-of levels.
    Alex: I love that example, because I hear so much of what we’ve talked about today — complexity, size, but people working together, the right people identified and brought in early, and the data validated and understood at each stage. Anthony, any final thoughts?
    Anthony: I’ll follow up on what Simon said. What made that particularly successful is the petabytes of messaging data we got rid of. This was an organization with lots of legal holds and regulatory scrutiny, but because we did it the right way, we got legal to sign off on deleting tons of it — an entire environment was gotten rid of, and now they’re in a modern archive and can manage that data better. It was incredibly complex, but if you do it right, you get the success.

    Closing

    Alex: Thank you, everyone, so much for your time, and thank you to everyone listening. I really enjoyed this conversation — I thought it was meaningful. As I said at the top, this is a topic that needs to be talked about more, not just by us, because it’s the only way we’re going to make these moves. Thank you, everyone, and have a lovely rest of your day.
    Anthony: Thank you.
    Tom: Thanks, everyone.

Q&A

Why is migrating an archive so daunting?

Because your archive holds the crown jewels, and the fears stack up: data leakage or spoliation, losing the ability to discover records, and regulatory exposure if data is corrupted in transit. Many firms also fear that extracting large volumes will crash an already-fragile legacy platform, so they do nothing. And the two questions everyone asks — what will it cost, and how long will it take — add to the hesitation.

Can’t we just keep the old archive running and let it “die on the vine”?

Not really. As the panel put it, data doesn’t die on the vine — the technology dies, but the data stays, because there are always legal holds and no one’s done the work to delete it. Leaving it is a decision to keep it, and it’s pure risk with no business benefit: litigation exposure, privacy exposure, and ongoing storage cost. You’ll have to migrate eventually, so plan for it.

How long does a migration actually take, and what takes the time?

Moving the data is now the fast part — the tooling has caught up. What takes time is testing, validation, and chasing down anomalies, which are almost guaranteed with older data. That’s why the panel recommends two to three months of planning and a proof of concept upfront. Skipping that and migrating everything first usually means discovering it was done wrong and doing it twice.

What does a solid migration plan include?

Preparation and data mapping first: know where your data sits, what sources came in, and how it’s used today versus how you’ll use the new platform. Crucially, identify every stakeholder — security, records management, legal, compliance — and bring them in early, because each has due diligence and a sign-off gate. The difference between success and failure often comes down to putting the user, not just the data, at the center.

How do we get legal and compliance to sign off on decommissioning the old archive?

Set the expectation early that someone will have to put their name to deleting what could be billions of messages. Explain that a small error rate is standard when migrating at that scale, and get them to accept it. Then document everything — chain of custody, error reports, and message-level reconciliation — because that audit trail is exactly what regulators and your own sign-off require.

What is reconciliation, and why does it matter so much?

Reconciliation proves nothing was lost. It runs in three phases: inventory the source platform on its own, confirm the migration tooling matches that inventory, then confirm what arrived in the target matches what the tooling reported — ideally with a unique identifier tracking each item end to end. Without it, when discovery searches don’t match between old and new, legal sees a problem and won’t sign off.

How do we avoid getting locked in by a vendor?

Read the contract before you sign. Legacy vendors often handcuff clients with large export or exit fees, effectively holding your data hostage on the way out. Insist that your data remains yours, retrievable at no cost, and scrutinize the support and end-of-life terms. Since change is continuous — there will always be a newer tool — portability should be built into the agreement from the start.

How are AI and new channels changing what we have to archive?

Dramatically. For the first time in twenty-five years, email volume is starting to fall while Teams, Bloomberg, and in-app chat features explode — so it’s a messaging archive now, not an email archive, which makes identity management critical. Regulators are moving too: FINRA recently clarified that customer interactions with AI tools count as electronic communications that must be captured.