Case Study: Redesigning RevMigrate’s AI-Powered Legacy Migration Platform

Here's something most people outside of enterprise IT never think about:

Underneath every large organization — every bank, every insurer, every hospital system, every government agency — there are databases. Old databases. Databases built in the '90s, running stored procedures written by engineers who left the company a decade ago, holding business logic that nobody fully documents because it just works.

Until it doesn't.

Until the infrastructure can't scale. Until the vendor stops supporting it. Until the cloud migration mandate arrives from the C-suite. Until someone realizes that the system running 40% of the company's operations is a liability that nobody completely understands.

That's when migration becomes necessary. And that's when teams discover the real problem:

Before you can move a system, you have to understand it.

And most of the time, nobody does.

"Migration projects don't fail because the technology is hard. They fail because nobody fully understood the system they were trying to move."

What RevMigrate was — and what it needed to become

RevMigrate, built by RevUpAI, was already a functional platform when we arrived. It could connect to legacy databases, analyze structures, use AI to transform code, and generate documentation for migration projects.

The technology was impressive. The workflows were powerful.

The experience was falling behind.

As the product evolved — adding new capabilities, supporting more database types, integrating deeper AI workflows — the interface hadn't kept pace. Features were added but not organized. Workflows existed but didn't connect. Critical information was available but not visible.

The platform had the power to help enterprises modernize their legacy systems. But using that power required users who already understood the platform's internal logic — which is a polite way of saying the product had become its own legacy system.

What we found

Navigation had become a maze. Features were scattered across multiple areas without a clear organizational logic. Users bounced between sections to complete a single workflow.

Dependencies were invisible. The platform analyzed database relationships — tables, stored procedures, triggers, views — but presented them as lists and tables. Spreadsheet views of interconnected systems. Like reading a blueprint by looking at a parts list.

AI transformations felt like a black box. The system could transform legacy code into modern implementations, but users had limited visibility into what was generated, why, and whether they should trust it.

Progress was unmeasured. Migration projects span weeks or months. Users had no clear way to understand: how far along are we? What's been transformed? What still needs attention? What's risky?

The product felt like every other enterprise tool. Greys, blues, dense tables, generic dashboards. For a product powered by AI — doing genuinely novel things — the experience felt like it could have been built in 2012.

Understanding the users

RevMigrate's users weren't casual. They were deeply technical professionals managing high-stakes transformation projects:

Database administrators — the people closest to the legacy systems. They connect databases, run scans, understand structures. They care about accuracy and completeness.

Solution architects — the people making strategic decisions. Which systems migrate first? What's the dependency risk? How complex is this going to be? They care about visibility and feasibility.

Migration engineers — the people doing the transformation work. They review AI-generated code, compare outputs, push changes, validate results. They care about quality and traceability.

Enterprise consultants — the people reporting to stakeholders. They need documentation, progress metrics, and risk assessments. They care about clarity and communicability.

Platform administrators — the people governing access and operations. They manage users, roles, and organizational settings. They care about control and compliance.

Each of these roles interacted with the platform differently. But they all shared one need:

Understanding what they were dealing with before making decisions.

The insight that reframed everything

During research, we kept hearing the same frustration expressed in different ways:

"I can see the tables, but I can't see how they relate to each other."

"The AI generated code, but I don't know if it's handling the edge cases in the original stored procedures."

"I know the migration is happening, but I can't tell you where we actually are."

Every complaint was a variation of the same problem: lack of visibility.

The platform had the data. It had the analysis. It had the AI. What it didn't have was a way to make all of that visible — to surface understanding instead of burying it in tables and configurations.

This became the foundational principle for the entire redesign:

"Visibility reduces uncertainty."

Migration is inherently risky. Organizations are moving systems they depend on. The product couldn't eliminate that risk — but it could eliminate the uncertainty that makes risk unmanageable. If users could see dependencies, track progress, understand AI outputs, and identify problems — they could make better decisions.

The redesign wasn't about adding features. It was about revealing what the platform already knew.

"The platform had all the intelligence. It just didn't show its work."

Restructuring the platform

The existing architecture organized features by technical function — databases here, AI there, settings somewhere else. Users had to understand the platform's internal structure to navigate it.

We reorganized around how migration teams actually work:

1. Project & Migration Oversight

"Where are we? What needs attention?"

The strategic layer. Dashboards, progress tracking, project status, risk indicators.

2. Database Analysis

"What are we dealing with?"

The understanding layer. Connections, scans, object exploration, dependency mapping.

3. AI Transformation

"What's been generated? Can we trust it?"

The action layer. Code transformation, review workflows, documentation generation, deployment.

This structure matched the natural progression of a migration project: understand the system → transform its components → track progress toward completion.

Users didn't need to learn the platform's architecture. They just needed to know where they were in the migration process.

The dashboard as command center

The old homepage was a landing page. Some stats. Some links. Generic welcome content.

The redesigned dashboard was a command center — designed to answer the question every user asks when they log in: "What's happening right now?"

Within seconds of landing, users could see:

• Active database connections — what systems are connected and scanned

• Analysis completion — how much of each database has been analyzed

• Objects transformed — stored procedures, functions, triggers converted by AI

• Migration progress — overall project advancement

• Feature availability — which platform capabilities are active

• AI recommendations — suggested next actions based on project state

Each metric wasn't just a number. It was a doorway — clicking any card navigated directly to the relevant workflow. The dashboard wasn't a report. It was a launch pad.

"The old dashboard told you facts. The new dashboard told you what to do next."

Database connection: the first five minutes matter

For a new migration project, the first interaction with RevMigrate is connecting a database. If this feels complicated, confidence drops before the real work even begins.

The original connection flow exposed configuration complexity upfront — host, port, credentials, advanced settings, validation parameters — all on one screen.

We redesigned it as a guided three-step process:

Step 1: Select your source. Oracle. Sybase. PostgreSQL. MySQL. SQL Server. Amazon RDS. Amazon Athena. Clear visual cards showing supported databases. Pick one.

Step 2: Configure your connection. Only the fields relevant to the selected database type. Host. Port. Database name. Credentials. Advanced settings available but collapsed by default — visible for power users, invisible to everyone else.

Step 3: Validate and scan. One action. The system tests the connection, confirms access, and initiates the database scan. Progress is visible. Errors are specific and actionable.

Three screens. Clear progression. A migration project goes from "where do I start?" to "scanning in progress" in under two minutes.

The scan that doesn't lock you out

Here's a detail that seems small but mattered enormously: database scanning happens in real time, streamed through WebSocket connections.

Why does this matter? Because scanning a large enterprise database — thousands of tables, stored procedures, triggers, views — takes time. Sometimes significant time.

In the original experience, initiating a scan felt like throwing a request into a void. Users clicked "scan," the screen went quiet, and they waited. No feedback. No progress. No indication of whether the process was working or had stalled.

We redesigned the scan experience around live streaming updates. As the backend analyzed the database, object counts, schema discoveries, and analysis progress streamed directly to the interface through a persistent WebSocket connection. Users could watch their database being mapped in real time — tables appearing, procedures cataloged, dependencies emerging.

More importantly, the UI remained fully interactive during scanning. Users could navigate to other areas of the platform, review previously analyzed databases, or start configuring settings — while the scan continued in the background with a persistent status indicator keeping them informed.

No blocking. No waiting. No void.

Exploring database objects

Once a database is scanned, RevMigrate catalogs everything it finds:

• Stored procedures

• Functions

• Packages

• Triggers

• Views

• Tables

In the original platform, these were presented as flat lists — long tables of names, types, and statuses. For a database with thousands of objects, this was effectively unusable. Finding what mattered required knowing what you were looking for in advance.

We redesigned object exploration around progressive discovery:

Overview level — see the total landscape. How many objects of each type? What's the overall complexity? What percentage has been analyzed or transformed?

Category level — drill into a specific type. Filter, sort, search within stored procedures or functions. See transformation status at a glance.

Object level — examine an individual object in full detail. Dependencies. Generated business documentation. AI-transformed code. GitHub push status. Deployment readiness.

At every level, users could take action:

• Review dependencies

• Generate documentation

• Open transformed code

• Push to GitHub

• Deploy transformations

• Regenerate AI outputs

The hierarchy wasn't just organization. It was contextual decision-making — each level answered different questions at different stages of the migration process.

The dependency visualization: the feature that changed everything

This was the hero of the redesign. And honestly, one of the most interesting design challenges we've worked on.

The problem with spreadsheets

Most migration tools present database dependencies as tables. Object A depends on Object B. Object B depends on Objects C and D. Object C depends on Object E.

Read that sentence again. Now imagine it with 3,000 objects.

Spreadsheets can store dependency data. They cannot communicate dependency relationships. When a solution architect needs to understand "what happens if I migrate this stored procedure?" — a spreadsheet forces them to mentally trace chains of relationships across hundreds of rows.

Humans don't understand complex systems through rows and columns. They understand them through spatial relationships.

The visualization

We designed an interactive dependency graph — powered by Cytoscape.js with DAGRE and FCOSE layout algorithms — that transformed flat data into a spatial, navigable map of system relationships.

The layout engine choice mattered. DAGRE (directed acyclic graph rendering) organized hierarchical dependencies — upstream and downstream chains — into clean, readable flows. FCOSE (force-directed compound spring embedder) handled the messier reality of tightly coupled clusters, distributing interconnected objects spatially so that patterns emerged naturally instead of being forced into rigid hierarchies.

The result was a graph that could handle both clean dependency chains and the tangled reality of legacy systems that had twenty years of undocumented cross-references.

Users could see:

• Direct relationships — what this object connects to

• Upstream dependencies — what feeds into this object

• Downstream impacts — what breaks if this object changes

• Object clusters — groups of tightly coupled components that should migrate together

• Isolated objects — components with no dependencies that can migrate independently

• Risk pathways — chains of dependencies where a single failure cascades

The graph was interactive:

• Click an object to highlight its dependency chain

• Zoom in to examine clusters

• Zoom out to see system-wide patterns

• Filter by object type, status, or risk level

• Toggle between dependency views

This didn't just visualize data. It became a decision-making tool.

A solution architect looking at the dependency graph could identify: "This cluster of 47 interconnected stored procedures needs to migrate as a unit. But this group of 12 functions is completely independent — we can move those first with zero risk."

That insight — derived visually in seconds — would take hours to extract from a spreadsheet.

"Dependencies as a spreadsheet: data. Dependencies as a graph: understanding. Same information. Completely different insight."

The design challenge inside the visualization

Building a graph that displays thousands of nodes without becoming an unreadable hairball was a significant design problem.

We addressed this through:

Intelligent clustering. Tightly coupled objects were grouped visually, reducing visual noise while preserving relationship accuracy.

Progressive detail. At the highest zoom level, users see clusters and patterns. Zooming in reveals individual objects and connections. Zooming further shows object details and metadata.

Selective highlighting. Clicking any node highlighted its direct dependency chain and dimmed everything else. This turned a complex graph into a focused relationship map instantly.

Filtering. Users could filter by object type, transformation status, or risk level — showing only the subset of the system they were currently working on.

The visualization had to be powerful enough for architects planning migration strategy and simple enough that it didn't require a training manual.

AI code transformation: automation with accountability

RevMigrate's AI could do something remarkable: take legacy code — stored procedures written in Oracle PL/SQL or Sybase Transact-SQL — and transform it into modern implementations for target platforms.

This is genuinely difficult work. Legacy code contains business logic that's often undocumented, edge cases that were handled decades ago by engineers who've since left, and conventions that made sense in their original context but don't translate directly to modern architectures.

The AI handled the transformation. The design challenge was: how do you help humans trust and verify AI-generated code?

The review workflow

We designed the code transformation experience around a principle borrowed from our SARGE project: AI works best when paired with transparency and human review.

For every transformed object, users could:

• Review the generated code — full output, syntax-highlighted, formatted for readability

• Compare with the original — side-by-side diff view showing what changed and why

• Fine-tune the output — make manual adjustments to AI-generated code

• Regenerate — if the output wasn't satisfactory, rerun the transformation with different parameters

• Push to GitHub — export approved code directly to version control

• Deploy — move validated transformations toward production

The workflow never assumed the AI was right. It assumed the AI was helpful — and gave humans the tools to verify, adjust, and approve.

"The AI didn't replace migration engineers. It gave them a first draft — and the tools to make it right."

The AI layer: Prompt Vault and contextual assistant

RevMigrate's AI wasn't a single feature. It was a layer that ran through the entire platform — manifesting in two distinct experiences.

The Prompt Vault

The Prompt Vault was a library of reusable, migration-specific AI prompts — curated queries that encoded institutional knowledge about common migration scenarios.

Instead of expecting every user to know how to prompt an AI for migration analysis, the Vault provided proven starting points:

• Complexity assessment prompts for specific database types

• Risk identification queries for dependency clusters

• Documentation generation templates

• Transformation strategy recommendations

• Stakeholder-ready report generators

Teams could save, share, and refine prompts — turning individual migration experience into organizational knowledge. A prompt that worked well for one Oracle-to-cloud migration could be reused across future projects.

The contextual chatbot

Alongside the Prompt Vault, a contextual AI assistant remained available throughout the platform. Unlike generic chatbots that answer broad questions, this assistant was purpose-built for migration workflows.

Users could ask:

• "Generate a migration plan for this database"

• "What's the complexity assessment for this cluster?"

• "Identify the highest-risk dependencies"

• "Recommend a transformation sequence"

• "Explain what this stored procedure does"

• "Generate a summary report for stakeholders"

The assistant understood the user's current context — what database they were looking at, what objects they'd selected, what stage of the migration they were in — and provided relevant, actionable responses.

It behaved less like a chatbot and more like a senior migration consultant who happened to have perfect recall of every object, dependency, and transformation in the project.

The Prompt Vault and the chatbot worked as a system: the Vault provided structure and repeatability, the chatbot provided flexibility and exploration. Together, they turned AI from a novelty feature into an operational tool.

Document analysis hub

Migration projects generate enormous volumes of documentation:

• Business documentation explaining what legacy systems do

• Technical documentation detailing database structures

• Generated reports on dependency analysis

• Transformation outputs and code reviews

• Migration plans and risk assessments

In the original platform, documentation was scattered — generated in different workflows, stored in different locations, accessible through different paths.

We centralized everything into a Document Analysis Hub — a single interface where users could access, search, download, and share every document the platform generated.

For enterprise consultants who needed to present migration progress to stakeholders, this was transformative. Instead of collecting artifacts from multiple platform areas, they could pull everything from one place.

The visual identity: deliberately different

This is one of the design decisions we're most proud of — and it might seem superficial until you understand the reasoning.

Enterprise software defaults to blue. Sometimes grey. Occasionally teal. The visual message is always: "We are serious. We are reliable. We are exactly like every other enterprise tool you've ever used."

RevMigrate was not like every other enterprise tool. It was an AI-powered platform doing genuinely novel work — analyzing legacy systems, visualizing dependencies, generating code transformations. The visual identity needed to communicate that difference.

Electric Violet (#9400FF)

The primary color. Used for primary actions, AI workflows, and key interactions.

Violet is unusual in enterprise software. That was the point. It signaled:

• AI intelligence — violet has strong associations with AI and advanced technology

• Differentiation — the platform wouldn't be confused with traditional migration tools

• Premium positioning — the color feels intentional, not default

• Modernity — distancing from the legacy systems the platform helps migrate away from

Persian Indigo (#27005D)

The secondary color. Used for depth, backgrounds, and hierarchy.

The deep indigo created a premium, immersive environment — particularly on the dependency visualization and dashboard screens where dark backgrounds let data and relationships take visual priority.

The combined effect

The violet-indigo palette created an interface that felt like mission control for a modernization project — dark, focused, and alive with highlighted information.

It wasn't a consumer aesthetic. It wasn't a startup aesthetic. It was a new enterprise aesthetic — one that took the seriousness of enterprise tooling but refused to inherit the visual boredom.

"Enterprise software doesn't have to look like it was designed by a committee that agreed on 'safe.' RevMigrate looked like it was designed by people who believed the work they were supporting was extraordinary."

The design system

RevMigrate's design system was built for a specific tension: data density and visual clarity, simultaneously.

Typography: DM Sans

Selected for its performance in data-heavy environments. DM Sans provided:

• Clean readability at small sizes (critical for code views and table data)

• Modern personality at large sizes (dashboards, headings, feature areas)

• Professional weight that matched the enterprise context

• Sufficient character set for code-adjacent content

Components built for migration workflows

Connection cards. Database connections displayed as status-rich cards showing type, status, scan progress, and object count. Each card was a miniature project summary.

Object tables. Dense, sortable, filterable tables designed for navigating thousands of database objects. Inline status indicators showed transformation progress without requiring row expansion.

Graph components. Custom visualization elements for the dependency graph — nodes, edges, clusters, highlights, and interactive controls. These didn't exist in any component library. They were designed specifically for RevMigrate's graph architecture.

Code blocks. Syntax-highlighted code display with diff support, line numbering, and inline annotations. These needed to feel native to developers while being accessible to non-technical reviewers.

Progress indicators. Migration is a long process. Progress components appeared across dashboards, object lists, and project views — always showing how far along the work was.

Status system. A unified visual language for status across every entity: connected/disconnected, scanned/unscanned, transformed/untransformed, reviewed/unreviewed, deployed/pending. Consistent everywhere.

User and role management

Enterprise migration projects involve multiple teams with different responsibilities and access needs.

The platform's governance layer supported:

• User management — invite, configure, and manage team members

• Organization management — multi-tenant support for consulting firms managing multiple client migrations

• Role-based access — define what each role can see, modify, and deploy

• Administrative controls — platform-level governance and operational settings

The design challenge: making governance feel like a natural part of the platform, not an administrative afterthought. Users managing permissions should feel the same design clarity as users exploring dependencies.

What made this project uniquely challenging

Visualizing systems that nobody fully understands.

The entire product premise is that legacy systems contain more complexity than anyone realizes. But designing a visualization for a system nobody fully understands means you can't validate completeness. You have to trust that the analysis engine is finding everything — and design the interface to surface surprises rather than confirm expectations. The dependency graph had to be an exploration tool, not just a confirmation tool.

Making AI code generation trustworthy.

Developers are instinctively skeptical of generated code. Twenty years of bad code generators have trained them to distrust anything they didn't write. The transformation workflow had to overcome that skepticism — not by hiding the AI, but by making it more transparent. Show the original. Show the transformation. Show the diff. Let the developer interrogate every decision.

Balancing density for different technical depths.

Database administrators want to see raw object details, connection strings, and scan metadata. Solution architects want to see patterns, clusters, and risk assessments. Enterprise consultants want to see progress percentages and executive summaries. The same platform — sometimes the same screens — had to serve all three depths without overwhelming the shallow end or boring the deep end.

The graph performance problem.

Interactive visualizations with thousands of nodes are computationally expensive. The dependency graph needed to be responsive — real-time highlighting, smooth zooming, instant filtering — even with large databases. This wasn't just a design challenge. It was a design-and-engineering challenge that required compromises on both sides: simplified rendering for large graphs, progressive loading for deep zoom levels, and strategic clustering to reduce visual complexity.

Building on a moving foundation.

RevMigrate's capabilities were evolving during the redesign. New database sources were being added. New AI transformation models were being integrated. The design system had to be flexible enough to accommodate features that hadn't been built yet — without becoming so generic that it lost specificity for the features that existed.

Development alongside design

The redesigned platform was implemented in Angular, with our team contributing to frontend development alongside the design work.

The application was architected around modular, lazy-loaded domains — Dashboard, Database, Settings, and AI components each lived in their own modules, loaded on demand. This wasn't just a technical decision. It was a performance decision that directly affected user experience: a solution architect opening the dependency graph didn't need to wait for the settings module to load. A telecaller checking scan progress didn't carry the weight of the code transformation interface.

This had the same benefits we've seen in other projects where design and development overlap — plus a few unique to RevMigrate's complexity:

• Design decisions validated against real data. A dependency graph that looks elegant with ten demo nodes might collapse with three thousand real ones. Building let us test with reality.

• WebSocket integration tested under load. The real-time scan streaming that looked smooth in prototypes needed engineering validation with actual enterprise databases producing hundreds of events per second.

• Interaction patterns proven in code. The code comparison view, the Cytoscape graph interactions, the guided connection flow — these were complex interactions that needed implementation validation, not just prototype validation.

• The design system became living code. Components existed as both design assets and Angular components. Consistency wasn't a style guide. It was a shared codebase.

The platform continued evolving after our engagement — additional features introduced during development extended the product beyond the original design scope. The design system was built to support that growth.

Reflection

RevMigrate reinforced something we've come to believe strongly:

The hardest design problems aren't about making things look good. They're about making complex things visible.

A dependency graph isn't a design flourish. It's the difference between an architect guessing and an architect knowing. A code comparison view isn't a feature — it's the mechanism that makes AI-generated transformations trustworthy. A dashboard metric isn't a number — it's situational awareness for a project that spans months.

A few things this project crystallized:

Visibility is the product.

RevMigrate's technology was already powerful. The redesign didn't make the AI better or the analysis deeper. It made the results visible. It surfaced understanding. That visibility — not the underlying capability — was what transformed the product from a technical tool into a strategic platform.

Developer tools deserve great design.

There's a persistent myth that technical users don't care about design. That if the tool is powerful enough, the interface doesn't matter. RevMigrate disproved this completely. Solution architects spending hours in dependency views, migration engineers reviewing generated code all day — these users benefit more from good design, not less, because their work is cognitively demanding.

Spatial thinking beats tabular thinking for complex systems.

Dependencies as a table: data. Dependencies as a graph: understanding. This wasn't a preference or an aesthetic choice. It was a fundamental difference in how humans process relational information. The graph didn't add new data. It presented existing data in a format that matched how the human brain processes connections.

AI needs a trust architecture.

AI-generated code is valuable only if users trust it enough to act on it. Trust isn't achieved by hiding the AI or by adding disclaimers. It's achieved by showing the work — original code, transformed code, differences highlighted, review controls available. Transparency is trust architecture.

Enterprise software can be beautiful and serious simultaneously.

The electric violet palette was a small rebellion against the grey-blue sameness of enterprise tooling. It didn't make the product less serious. It made it memorable. Users spending hours in a migration platform deserve an environment that feels intentional, not inevitable.

What RevMigrate became

RevMigrate went from a powerful-but-opaque migration tool to a platform that made legacy modernization visible.

Teams could connect to legacy databases and see — actually see — the systems they were dealing with. They could trace dependencies visually instead of mentally. They could review AI-generated transformations with full transparency. They could track migration progress in real time. They could make strategic decisions based on spatial understanding rather than spreadsheet analysis.

Not a database migration tool.

A legacy modernization platform — one that understood that the hardest part of migration isn't moving data.

It's understanding what you're moving.

TYPOGRAPHY: DM SANS

ICONS: TABLER ICONS

COLORS: ELECTRIC VIOLET (#9400FF) · PERSIAN INDIGO (#27005D)

TECHNOLOGY: ANGULAR