Database Migration Team Roles: Who Does What (and Why It Matters)

Moving a database from one system to another is a team sport. And like any good team, everyone has a job to do, and a successful migration depends heavily on these people behind the scenes.

Let's break down who's usually involved in a database migration project, what they do, and why their roles are so important for different aspects of the project.

Why the Right Team Matters

As Oracle says, 80% of database migration projects go over budget or time, and 30% is the average cost overrun. It's largely because of poor planning and unclear responsibilities, but that's totally avoidable with a clear division of roles. The right people:

• Keep the project on track        

• Avoid communication breakdowns        

• Prevent downtime and data loss        

So, who are these people?

Read more: Six data migration myths that may be costing you time and money

Project Manager

Without project managers, the whole performance could fall apart. In data migration projects, the PM makes sure everyone knows what to do, when to do it, and how to stay in sync with the rest of the team.

Their responsibilities include:

• Creating the migration roadmap        

• Defining milestones (like when the test environment should be ready or when data validation should begin        

• Assigning tasks to each team member based on their role        

• Keeping the project within the set budget        

They also run regular check-in meetings and communicate progress (and roadblocks) to stakeholders. They're also the ones who keep cool when things get stressful, like when a key test script fails or a deadline is suddenly moved up. A strong PM means the difference between a smooth migration and a chaotic scramble.

At Red Soluciones, when we migrated 50 databases from Sybase SQL Anywhere to PostgreSQL with SQLWays over seven months, our PM was critical. They managed dozens of moving parts:

• Scheduling downtime windows with clients        

• Coordinating with DBAs and developers across time zones        

• Even building a backup plan when a vendor delay threatened our timeline.         

Thanks to that leadership, we avoided serious delays and hit our migration goals.

Read more: Red Soluciones Tecnológicas, Ecuador, Migration to PostgreSQL

Database Administrator

The DBA is the person keeping the engine running behind the scenes. They're deeply familiar with the structure, quirks, and behavior of the database systems, so they don't just push buttons but actively protect your data and ensure it performs well before, during, and after the migration.

Their work starts with setting up backup and recovery strategies. Thus, they ensure there's always a plan B if something goes wrong mid-move. They also tune performance on both the source and target environments, checking things like indexing, memory usage, and query execution time.

Data security is a big part of the DBA's job, too. They make sure permissions are carried over correctly, encryption is in place, and there are no open doors in your new environment. Before the migration, they assess risks and get the legacy system ready for the move. After the migration, they validate that data is transferred correctly: table counts match, indexes are in place, constraints are enforced, and so on.

DBAs also monitor the live cutover in real time. If there's a sudden spike in load or a migration job stalls, they're the ones who jump in to fix it fast. Most DBAs spend 20–30% of their time on tasks related to system upgrades, patching, and migrations, which are no side gigs but the core of the role.

At a large healthcare provider we supported, the DBA was reviewing index health during the staging migration and found a corrupted index that would've caused reporting delays if pushed live. Catching and fixing it saved at least two days of downtime and avoided patient record issues during peak usage hours.

Read more: Data migration with SQLWays: A Step-by-Step Guide

Data Architect

Then, before any data can be moved, it needs to be understood by the data architect. They look at the old system and figure out how it maps to the new one, making sure all the necessary relationships, logic, and data flows make the jump correctly.

Their job starts by analyzing both the source and target schemas. They figure out which tables and fields exist, how they’re related, and what might need to change to fit the new environment. Maybe you're moving data from a case-insensitive system to one that treats "User" and "user" differently. Maybe your target doesn't support a certain datatype used heavily in your old system. The data architect finds these mismatches before they become problems.

They also define transformation rules. For example, if date formats need to change, or if certain fields are being deprecated and replaced with new ones, the data architect specifies exactly how that should happen. They document these rules in a data mapping document, a source of truth that everyone from developers to QA uses.

Finally, they work closely with developers to refactor code, especially when business logic is baked into stored procedures, triggers, or views that won’t translate directly.

For example, when migrating from Sybase ASE to Azure SQL database, our data architect had to map hundreds of stored procedures and triggers. Some of these procedures used proprietary syntax that didn't exist in the Azure SQL database. By identifying these early and documenting alternatives in T-SQL, they avoided broken reports and missing calculations after go-live.

Application Owner / Business Analyst

It's a person who speaks both "IT" and "Business." Your application owner's or business analyst's job is to make sure that the database migration doesn't just "work" but works for the business.

These people have technical knowledge about what data really matters, as not every field, table, or record is mission-critical. The business analyst identifies what's essential and what can be archived or left behind. They also spot risk areas, like workflows that rely on old triggers, or customer-facing features that might break if the data isn’t perfect.

They're also the ones who validate business functionality post-migration: Whether reports generate correctly, dashboards load, invoices print, and sales orders process the same way they did before.

And they're usually in charge of translating technical progress to non-technical stakeholders. If something's delayed or a key risk is discovered, they're the ones who explain why it matters in business terms.

Developers

Developers are the hands-on builders of your migration. When you're moving from one database platform to another, there's usually a lot of code that has to come along for the ride. But that code often needs refactoring, especially when moving from something like Sybase ASE to SQL Server or Oracle to PostgreSQL.

That might mean rewriting stored procedures, converting proprietary functions, or swapping out system-specific syntax. Developers are the ones doing that translation.

But their role doesn't stop there. They are also responsible for building test scripts, or automated checks, that ensure the new system behaves like the old one. And they often help with integration, adjusting applications to connect to the new database. That might involve updating connection strings, modifying ORM (object-relational mapping) layers, or adapting APIs that rely on specific query behavior.

Here's a quick look at what developers do depending on the migration type:

Even small changes, like how NULLs are handled or how timestamps are stored, can throw off entire workflows. Developers catch and fix all these before they go live.

QA/Test Engineer

You know who doesn't trust "it looks fine"? A QA engineer. And that's a good thing.

QA, or Quality Assurance, is a continuous process throughout a migration. It starts with designing thorough test plans that cover all the business-critical paths. Then they automate as much of the testing as possible, so checks run repeatedly, quickly, and without human error.

One of their biggest jobs is data accuracy and integrity testing. That means comparing what's in the old system with what's in the new one, and flagging anything that doesn't match. Sometimes they’ll use hash comparisons, record counts, or custom scripts to verify every row.

They also run regression tests to make sure nothing breaks in the applications that depend on the database. If someone updates a stored procedure and accidentally changes the return format, the QA team catches that.

Companies with dedicated QA teams during migrations can see as much as a 40% reduction in post-go-live bugs. That's fewer late-night calls, fewer angry users, and less scrambling for hotfixes.

Security Engineer

This is one role that's often overlooked during migrations, but it absolutely shouldn't be. When you move a database, you also move your security perimeter. And if it's not rebuilt carefully, your data could be exposed.

Security engineers start by auditing user permissions: that access roles in the new system match what was in place before, and that no one gets more access than they should. A migration is the perfect time to clean up old users, overly broad privileges, and legacy accounts that no one uses anymore.

They also verify encryption, both at rest and in transit. Whether you're migrating to a cloud platform or another on-premises solution, encryption settings vary, and they must be configured properly.

Firewalls and access controls need to be adjusted, too. A server that was only accessible inside your network might now be in the cloud, requiring new VPCs, IP restrictions, or VPNs.

Lastly, security engineers are your watchdogs for compliance. If your business needs to meet standards like GDPR, HIPAA, or SOC 2, they ensure that every piece of the new database is compliant, down to audit logs and data residency.

Cloud or Infrastructure Specialist

When your database migration involves moving to a new environment, especially to the cloud, you need someone who understands the plumbing, or a cloud or infrastructure specialist. They are the engineer who build the roads, bridges, and traffic lights before the cars (your data) ever start moving.

Their job starts with provisioning the new cloud environment, AWS, Azure, GCP, or a private cloud, with virtual machines, managed database instances, secure storage, and so on. This includes sizing them properly based on performance needs and expected traffic.

Next, they handle network setup, configuring VPCs, VPNs, subnets, private endpoints, or hybrid connectivity with on-prem systems. They make sure the source database talks to the target systems without interruptions or latency problems. If you're working across multiple regions or with a complex topology, this role becomes even more crucial.

Load balancing and high availability (HA) setups also fall under their domain. They configure clusters, failover groups, or geo-replication, whatever's needed to keep things running even if part of the system goes down. For mission-critical systems, this is a must.

They also set up monitoring and logging. This includes things like Azure Monitor, AWS CloudWatch, or open-source tools like Prometheus and Grafana. Logs need to be collected in real-time to track errors, performance drops, or unauthorized access attempts. Without these, issues fly under the radar until users start complaining.

Read more: Migrating to the Cloud Without Downtime: The Complete Checklist

Final Thoughts

Database migrations go beyond scripts and servers, involving many professionals and the way they collaborate. Every role we covered here adds value, and if one is missing or poorly defined, things can fall apart fast.

So, whether you're planning your first migration or your fiftieth, take time to build the right team, know who does what, and make sure everyone's on the same page.

Because in the world of successful data migration, teamwork is mission-critical. Want help defining your migration team structure? Let's chat. Our database migration dream team has helped many companies of all sizes move to their fresh environments with SQLWays!