When you’re planning a tech migration, you need to define your objectives. Think about when you move house. It’s the perfect time to take a long, hard look at your possessions, lose what you don’t need, and keep what’s necessary to thrive in your new home. Yet there’s a temptation to avoid the difficult decisions and pack every drawer exactly as it is, recreating the same clutter somewhere more expensive.
Unfortunately, that’s also how many technology migrations begin. Everything’s included. Every active matter, closed matter, archive, template, report, script, integration and workaround is treated as if it has automatically earned a place in the new environment. That can feel safe because it’s familiar, but often it simply recreates complexity, cost and old habits on a more modern platform.
Don't delay the difficult decisions
When it comes to decluttering a home, Marie Kondo might ask whether an object sparks joy. In a RelativityOne migration, the more practical question is whether each matter, workflow, script, report or integration still serves a purpose, supports the future operating model, or deserves to be rebuilt for the way the organisation wants to work next. It’s important that we take time to study the detail, look at what’s ahead and plan accordingly.
That discipline matters because the opposite extreme can be just as damaging. Move too little and your organisation may end up operating across two worlds: new project work in RelativityOne, and historical matters in Server or another legacy platform. The end result? Different processes, different search locations, and ongoing legacy cost. Avoiding hard migration decisions doesn’t necessarily reduce risk – it just spreads the pain over a longer period.
Your future operating model is key
A better starting point is not the migration tool, the transfer window, or the size of the data set – although those questions certainly matter, and they need experienced technical answers. Instead, consider the future operating model. What does the environment need to do after migration? Which matters need to remain searchable, accessible and usable? Which data is being retained defensibly but rarely accessed? Which workspaces still support active legal, regulatory or investigative work? Which can be archived, retired or left behind under a defensible plan? Be methodical, find the answers and you will set the foundations for a meaningful and productive migration.
Active matters require particular care. Remember that live investigations, active litigation, rolling productions, and time-sensitive regulatory responses may have limited tolerance for downtime. Likewise, review teams, counsel, clients and regulators may all depend on continuity. These constraints should shape your migration schedule, timing and method.
Custom workflows are often where the real unpacking begins. Scripts, agents, applications, integrations, field logic and bespoke processes may have become central to how teams work. Some will need to move, some will need to be rebuilt. Others may no longer be necessary because RelativityOne has native capability – or because the workflow itself should change to fit the new operating model, not the other way around.
Migrate, retire, rebuild, or replace
A useful protocol is in fact very simple: migrate, retire, rebuild, or replace. The discipline is not in naming the four options, it is in refusing to let everything quietly default to migrate.
Control Risks’ migration, managed services and development teams regularly work with organisations to assess existing environments, rationalise workflows and modernise custom applications. When it comes to large-scale migration work, a consistent pattern emerges: the biggest gains are often realised before the migration starts.
The goal is not to move everything. It is also not to move as little as possible. The goal is to move the right matters, data and workflows in a way that supports the environment in which the organisation wants to operate. Not everything needs to spark joy, but everything should have to earn the space it will occupy in RelativityOne.