relativity new context logos

The work we perform on behalf of our clients is typically classified as “development,” or “DevSecOps,” or “cloud native.” Each of these monikers implies a direct application of our engineering know-how. It’s true that there is almost always a hands-on portion to the work we perform on behalf of clients, however, our most critical and valuable work output starts much earlier in the process: evaluating the business needs that inform what ultimately should get built.

Often customers come to us with a problem, while the ideal solution remains elusive. Understanding the overlapping influence of business goals, policy, and process, and how they each drive the eventual technical solution, makes our work not only unique, but invaluable to our customers.

A Data Migration Challenge

For example, we were approached by Relativity, a global legal and compliance technology company, to help them solve a complex migration need. They were looking to migrate their legacy artifact management setup over to JFrog’s Artifactory. Data migration between package managers is a relatively simple job for our engineer consultants; the real (interesting) challenge of Relativity’s project stemmed from their business needs.

Relativity has a large development staff — approximately 500 developers spread across 80 teams — all of whom consume and produce artifacts from and for one another. Any extended disruption to that artifact’s service availability would have drastic effects on delivery and revenue. Maintaining service availability through the deployment was therefore a requirement.

The initial request was to have New Context consultants conduct an assessment of Relativity’s current landscape of projects and artifacts, then prepare a written timeline and roadmap “recipe” for executing the migration. The IT Operations staff would follow and execute the recipe in close coordination with development teams. Relativity initially estimated the entire effort would take 12 months from start to finish.

Relativity expected the high-level migration plan would look something like this:

relativity original data migration plan

The plan is simple and straightforward, both good qualities that we look for in all our activities; complexity adds more points of failure, which increases risk. However, our consultants immediately identified a potential flaw, which they later confirmed during the assessment: success was dependent on heavy individualized lift efforts (the blue roles in the image above) across the org, impacting every development team plus the support staff in IT. Teams had to shift endpoints in their code to use the new Artifactory system, whilst keeping the old artifacts available until they were migrated.

This meant that every team consuming artifacts had to look for artifacts based on a “hard transition” date, when uploads to the new system began. Handling that situation would require every team to add conditional date logic to their code to select the appropriate endpoint: older requests go to Legacy, newer ones to Artifactory. Remember what I said about complexity and risk? The “simple” plan suddenly doesn’t seem so simple.

The Solution: Seamless Data Migration Phases

Fortunately, New Context consultants further recognized that the original plan was a bit of a resourcing mismatch: utilizing manpower to address what was ultimately a tooling concern (accessing and migrating artifacts). If the problem is purely technical in nature, the reasoning went, then engineering should similarly provide a solution.

Following this line of thought, New Context engineers drafted up a new plan, using technology to address all concerns. They proposed putting a proxy in front of both artifact managers, which could do the work of translating requests between new and old systems as appropriate. It also eliminated the need for a hard transition date, allowing work to be completed in smoother stages. These stages are outlined in the graphic below:

new context seamless data migration phases

At first glance, this approach appears more involved than the original plan. However, it provides key benefits to reduce risk and cost that outstrip the added technical complexity:

Proxy serves all endpoints and delivers all data.

Whether the request points at a new or old endpoint, whether the data lives in the new or old repository, the proxy handles them all.

This access flexibility eliminated the need for coordination across multiple teams: everyone can begin uploading to the new repository immediately, while new and old resources remain accessible using new and old endpoint URLs.

Having legacy data accessible through the new system drastically reduces the pressure and urgency on IT Operations to perform a (riskier) data migration sooner and faster, allowing them to focus on stability and supporting teams with any weird edge cases.

Backend changes are invisible to affected teams.

Initial rollout of Artifactory with the proxy required no team-level code changes, and only enough downtime for DNS records to update. Dev teams continued working without interruption to development or delivery schedules.

All migration changes are zero-impact.

Teams updating endpoints in their code and IT migrating data in the background are explicit and independent changes: each team is free to conduct their own migration steps when/where it makes the most sense for them, and doing so won’t impact others inside the ecosystem. The reduction of splash damage down to zero reduces pressure and risk for everyone.

Teams update their code to redirect requests to Artifactory on a schedule that fits their availability, and theirs alone.

Minimal staff requirements to build and maintain the proxy.

All the power and flexibility of the solution hinges on the proper buildout of proxy functionality, which is a focused effort. New Context consultants would provide the necessary expertise and hands-on effort required to put it together, and then hand it off to a focused support team. Eliminating the large-scale coordinated migration removes individual development teams from the equation, representing a huge reduction in staff time (and therefore cost).

Data Migration Execution and Delivery

New Context presented this plan to Relativity and, based on the proposed benefits outlined above, agreed to move forward with the adjusted plan.

New Context built and delivered the entire solution using a small team of three senior consultants, coordinating closely with Relativity staff to conduct testing and ensure everything worked as intended. Pair programming exercises were conducted frequently with Relativity staff to ensure they had foundation knowledge of the platform long before any handoff had to occur.

Casey Ford, Manager of Software Engineering who leads the team overseeing all legacy and Artifactory package management at Relativity, had high praise for their experience throughout the project. “I appreciated how hands-on the NC consultants were,” Ford said. “They provided excellent documentation and instructional videos. I felt confident my team would be able to support the solution after hand-off.”

A scheduled delivery event launched the proxy into production transparently for all developers without extended downtime. New Context partnered closely with their Relativity counterparts through the following days to help address edge cases as they arose.

Simultaneously, New Context continued to refine and deliver detailed documentation on facets of the program, providing Relativity with go-to materials that complemented their experiences from pair programming and other 1-on-1 training sessions.

Relativity assumed complete operational control for the solution between Phases 2 and 3 in the chart above.

I appreciated how hands-on the NC consultants were…I felt confident my team would be able to support the solution after hand-off.

Data Migration Outcomes and Observations

  1. Relativity estimates that the seamless migration plan saved at least 15,000 hours of time spent across Engineering and IT departments, amounting to significant staff cost savings.
  2. By enabling individual migration efforts to happen asynchronously, Relativity saw the transition timeline reduced from 12 months (or more) down to just 4 months.
  3. Managing the migration dirty work behind the proxy removed the need for support efforts from individual engineers. IT Operations’ Tech Support Team was able to shoulder the support load without overtime or additional temporary overstaffing.
  4. The Nginx proxy design that New Context provided will be reused moving forward. Ford found this a pleasantly unexpected side benefit. “It has served as a blueprint for us in implementing blue-green deploys of other systems or services,” said Ford. “The construction and documentation are thorough, and have saved us even more migration hours on projects unrelated to our original engagement.”

Relativity had strong clarity about their current position, and where they wanted to ultimately arrive, but the in-between was all common shades of gray. It’s always wise to lean on tried-and-true approaches when dealing with the unknown, and Relativity’s initial plan wisely stuck to something that was easily understood across the organization. Unfortunately, that plan also came with a large price tag in the form of manual, individualized efforts, highly matrixed communication needs, and heavy support demands.

By partnering and getting deeply familiar with Relativity’s business goals, policy, and processes, New Context was able to bring their expertise in automation and cloud native to bear for Relativity’s benefits. Understanding the status quo and the final objective, New Context removed unknowns and provided a route that was cheaper, faster, and less risky.