Workday Data Migration in Higher Education:What Happens to Your Historical Data (2026)

The Question Nobody Wants to Answer Early

When an institution moves to Workday, the historical data question is often deferred. Teams focus on configuration, security, and go-live, and the decision about how much old data to bring forward gets pushed down the list until testing, when it becomes urgent and expensive.

That is the wrong time to figure it out. How far back you migrate, which records you carry, and what you do with the rest is a strategy decision that shapes cost, timeline, and risk from the first design workshop. It is also costly and disruptive to revisit after conversion design and testing are underway.

The good news: the question is answerable. It just needs to be asked early, with the right people in the room, and with a clear-eyed view of which data should be converted, summarized, archived or integrated, or defensibly disposed of.

This article focuses primarily on Workday Student and academic records, where historical-data decisions are often especially consequential. Finance and HR require their own record-by-record analyses.

Key Takeaways

Start With How the Data Will Be Used, Not How Much There Is

The instinct on most projects is to ask “how many years of data do we have?” The better question is “what will we actually need this data to do?”

Those are different questions with very different answers. A record you will never query again is a storage cost. A record you must produce on demand, accurately, for the rest of an institution’s life, is a design requirement. Until you separate the two, every estimate of migration scope is guesswork.

This is also where the cloud changes nothing fundamental. In a Banner world, part of the historical-data conversation was about infrastructure: servers, storage, performance during peak load. In Workday, the platform side belongs to the vendor. What remains is the part that was always the hard part, namely deciding what your institution needs to carry forward and why. The same holds true for institutions running a PeopleSoft-to-Workday migration or moving off Colleague. The vendor changes; the retention judgment does not.

Student Data Is Where the Pain Concentrates

If you take one thing from this piece, take this: student records are the demanding workstream, and they are demanding for reasons that have nothing to do with Workday.

Student data is large, it spans decades, and it has to be mapped from a legacy structure into a new model that almost never lines up cleanly. Underneath the volume sits the obligation that makes it unforgiving: transcripts and GPA continuity have to be furnished accurately, indefinitely. A registrar cannot tell a graduate from 1994 that their academic record did not survive the migration. The transcript is a permanent, legally significant document, and the institution owns that obligation forever.

That is why student data resists the tidy cutoffs that work elsewhere. You are not just storing the data, you are committing to reproduce it correctly long after the people who entered it have moved on. This is the same complexity we cover in our post on Banner data cleanup during Workday Student projects, where curriculum logic and legacy structures collide with new-system requirements.

Beyond the Transcript: The Registrar’s Perspective

A transcript is permanent, but it is only one piece of a student’s story. From a registrar’s perspective, the conversation goes beyond courses, credits, and GPA. Student records include years of academic decisions that may never appear on an official transcript but still matter long after implementation. Transfer evaluations, course substitutions, waivers, residency decisions, catalog changes, degree changes, academic standing history, and exceptions all help explain why a student’s record looks the way it does.

Think about the student who returns after eight years to finish a degree. Their transcript may tell you what they completed, but it may not explain why a requirement was waived, why a substitution was approved, or why they were allowed to follow a different catalog. Without that history, staff are left trying to recreate decisions that someone else already made years ago.

That’s why I encourage institutions to ask a different question early in the project. 

If Banner disappeared tomorrow, what information would your registrar’s office immediately miss?

The answer is almost never “just the transcript.” It is the history behind the transcript.

Historical reporting deserves the same attention. Leadership will still ask for graduation trends, enrollment history, accreditation data, and state reporting years after go-live. Registrar offices will still need to answer questions from advisors, auditors, employers, and former students. Planning how that information will be accessed is just as important as deciding whether it will be migrated.

The goal isn’t to move every piece of historical data into Workday. The goal is to make sure your institution can still answer the questions it will be asked five, ten, or twenty years from now.

Boomerang Students Are Why You Cannot Draw a Clean Line

Here is the registrar’s reality: students come back. Sometimes after two years, sometimes after twenty. A returning student with academic history in the old system creates immediate work if that history did not come along. You have to reconcile their prior coursework, GPA, and standing with the new record, and that reconciliation is far harder after the data has been left behind in a system you are trying to decommission. Every institution has the outlier too, the eighty-something still taking a class, whose records trace back through a campus name and a system that no longer exists. Those are the cases that generate the disproportionate effort.

You cannot migrate for the outliers, and you should not try. The workable approach is an 80–20 one: go back far enough to capture roughly 80 percent of the students realistically likely to return, accept that a small tail will require manual handling, and make that tradeoff on purpose rather than discovering it at a service desk two years after go-live. The point is to choose the line knowingly, with the registrar’s input, rather than letting a default decide it for you.

Test With Your Most Complicated Students

One recommendation I make during every student system implementation is to build testing around the students who are hardest to evaluate, not the easiest. A first-time freshman with one major, no transfer credit, and no exceptions probably isn’t going to expose many migration issues.

The students who will tell you whether your migration was successful are the ones with years of history. Returning students, multiple majors or minors, repeated coursework, substitutions, waivers, transfer credit from several institutions, catalog changes, or discontinued programs all put your data and business processes to the test. These are also the students registrar offices spend the most time helping after go-live.

If those records look right, confidence grows quickly. If they don’t, those issues are much harder to untangle once students begin registering, applying for graduation, or requesting transcripts. For more on how these scenarios should be built into UAT, see our guide to Workday Student testing and UAT readiness.

Testing isn’t just about confirming that data moved from one system to another. It’s about making sure your institution can continue serving the students whose records are anything but straightforward.

Finance Data Is the Easier Side of the House

Not all historical data carries the same weight, and finance is the clearest example of the lighter end.

Financial records come with retention rules that are comparatively clean. Much of it lives under well-understood standards, often a 7-year horizon for tax and audit purposes, with established practices for write-offs and collections. Accounts receivable has natural lines in the sand: you carry active balances and the people who still owe you from prior terms, and at some point uncollected balances get written off and moved to collections. That structure makes the keep-or-archive decision far more straightforward than it is on the student side.

The storage burden is lighter too. Historical finance data generally does not carry the volume and mapping complexity that student records do, so keeping a deeper history is often the low-cost, low-regret choice. When you are triaging where to spend migration effort, finance is usually not where the hard calls are.

HR and historical employee records sit somewhere in between. They can be a headache to migrate, but there is a saving grace: when an employee returns, their new position generally supersedes whatever lived in the old system. Unless there is a specific reason to preserve detailed historical employment notes, you can often start fresh, which is a luxury the registrar rarely gets.

Do Not Lose the Reasons Behind the Decisions

There is a category of historical data that does not show up in a record count, and it is the one institutions regret losing most: the documented reasoning behind past decisions.

That reasoning lives in the notes, the comments, and the institutional memory embedded in the old system. When it disappears in a migration, the institution does not just lose data, it loses the explanation, and the practical consequence is that people recreate old mistakes because no one remembers why the original decision was made.

Turnover makes this worse. The staff who carried the reasoning in their heads move on, and once both the documentation and the people are gone, the knowledge is unrecoverable. Preserving a deliberate slice of that decision history, even outside the primary migration, is cheap insurance against expensive relearning.

Institutional knowledge isn’t stored only in people’s memories. It’s also embedded in the tools and processes registrar offices have built over time.

Think about years of Degree Works substitutions, transfer articulation decisions, curriculum exceptions, petitions, committee approvals, and documentation supporting academic decisions. Those records tell the story behind the student’s audit, even when they never appear on a transcript.

Before retiring a legacy system, ask what information staff still reference today. If advisors or registrar staff regularly open Banner or Degree Works to answer questions about former students, that history deserves a place in your migration and archival strategy.

Not every record belongs in Workday, but every institution should know where that information will live and how staff will access it after go-live.

A Practical Workday Data Migration Strategy for Higher Education 

Pulling it together, here is how we coach institutions to approach historical data before it becomes a testing-phase fire drill:

None of this is Workday-specific, and that is the point. It is migration best practice for any new system. What a Workday Student deployment does is raise the stakes on the student-data piece, because the volume, the mapping, and the permanence of academic records all land in the same workstream at the same time.

The Bottom Line

The historical data question feels like a detail until it isn’t. Handled early, it is a series of deliberate, defensible choices about obligation, cost, and risk. Handled late, it becomes the workstream that explains why your go-live slipped and why a returning student’s record cannot be found.

The institutions that get this right do two things. They decide what they owe their data, students, finance, and the people who will inherit the system, before they decide how much to move. And they bring the registrar’s lens into the room early, because the person who has actually reconciled a boomerang student’s twenty-year-old transcript knows where the real cost hides.

Talk to Kent about your migration data strategy. We will help you classify what you owe, set defensible cutoffs, and protect the institutional knowledge that is easiest to lose and hardest to rebuild.