A legacy system case study.

I spent 15 years at Info-Pro helping lenders across the Midwest make sense of complex real estate tax data—delinquent searches, escrow amounts, discrepancies, and all the little nuances that come with it. Minnesota is its own animal.

Property tax servicing here is more complex because lenders aren’t just tracking tax amounts—they’re navigating installment payment schedules, county-specific collection practices, and delinquency processes that can vary across the state. What looks like a simple tax bill often requires a deeper understanding of how taxes are billed, collected, and enforced to ensure payments are made accurately and on time.

Related articles

A Practical Guide to Property Tax Timing & Risk Mitigation

Making The Switch From Legacy

Working with Minnesota lenders, we kept seeing the same thing: their data lived in all kinds of different platforms, methods, and applications. And for anyone thinking about switching service providers, the biggest friction point was simply getting their arms around all of it. They felt like the information had to be perfect before they could make a move—and getting it there ate up hours they didn’t have.

For the legacy service providers, the whole operating model depended on the data being accurate—and keeping it that way took an enormous amount of manual effort.

I think back to a well-respected mid-sized lender in Minnesota—12 branches, about $750 million in assets. From the outside, everything looked organized and under control. They’d had steady growth and a strong loan operations team behind the portfolio.

But once we sat down with the operations group to walk through their workflow and data management, a different picture emerged.

The team was juggling more than 400 spreadsheets across the organization as their main way of tracking and maintaining real estate tax data. There was a spreadsheet for delinquency tracking, another for escrow analysis, others for payment monitoring, parcel exceptions, and reconciling across systems.

One team member summed it up perfectly:

“The real estate tax data is probably on one of those spreadsheets. And someone has to manage or oversee the spreadsheets.”

That one comment captured the core issue so many lenders face today. It wasn’t a lack of discipline or effort—it was that the whole operation had grown up around managing fragmented data instead of getting rid of the fragmentation in the first place.

A Minnesota Operations Story

Minnesota piles on its own complexity. Most properties run on a two-installment structure, with deadlines usually in May and October. Agricultural properties march to a different schedule. Some counties publish their data earlier than others. Parcel formats are all over the place. And delinquency status doesn’t always line up cleanly from one source to the next.

To stay on top of all that, the team had built a system over the years.

Not a single system—but a collection of them.

They had:

  • A delinquency tracking file that flagged parcels past due after the May or October deadlines
  • An escrow reconciliation file that compared expected tax amounts against borrower balances
  • A payment tracking log that recorded what had been initiated, approved, and confirmed
  • Exception lists for parcels where data didn’t align across sources

On top of all that, they were pulling data from their core servicing platform, county websites, and third-party providers.

None of it lived in one place.

So the real work wasn’t just processing taxes—it was making sense of the data. They’d have a handful of spreadsheets open side by side and a browser full of county sites. They weren’t just reviewing information—they were analyzing it visually.

Looking for:

  • Parcels marked delinquent in one source but paid in another
  • Slight differences in tax amounts between systems
  • Installment payments that hadn’t been reflected yet
  • Timing mismatches based on county reporting delays

They leaned on color coding, filters, and notes to keep track of what they’d verified and what still needed a look. It was impressive. But it was also clear: This system worked because of the people—not because of the design.

The Hidden Cost of “Working”

From where leadership sat, everything looked under control. Payments were going out. Delinquencies were tracked. Escrow accounts balanced.

But look a little closer and you could see where the strain was hiding.

Every inconsistency required investigation. Every discrepancy required validation. Every update required manual coordination. And as their portfolio grew, so did the effort it took to keep that accuracy up.

I asked one of the team members how much time they spent each week just reconciling data between systems. They didn’t hesitate.

“A lot more than we should.”

That’s when the real issue came into focus. Their process wasn’t broken. It was built to make up for inconsistent data.

The Tradeoff That Kept Them There

When we started talking about modernization, the conversation turned to data almost immediately.

They knew their systems could be better. They knew their workflows could be tighter. But like a lot of lenders, they’d been through—or heard the horror stories about—conversion projects before. They knew exactly what it meant:

  • Cleaning up years of inconsistent parcel data
  • Aligning formats across systems
  • Filling in missing or incomplete records
  • Validating everything before moving it into a new platform

It wasn’t just a technology decision. It was an operational commitment.

And like a lot of institutions, they were stuck on the same tradeoff the industry has wrestled with for years:

Do we improve outcomes at the cost of significant disruption?

For them, the answer had always been no. Not because they didn’t want to improve—but because the path to get there felt too heavy.

The Real Bottleneck: Data and Conversion

This is where I’ve watched the industry get stuck. Not on technology. On data.

And because tax data is messy by nature—especially across jurisdictions—that one prerequisite turns into the biggest barrier of all. Conversion projects become:

  • Expensive, requiring dedicated internal and external resources
  • Time-consuming, often taking months before any value is realized
  • Resource-draining, pulling teams away from day-to-day operations

Over time, institutions just accept it as the way things are. Data cleanup is “part of the process.” Conversion is “what it takes.” But here’s the truth:

Those aren’t requirements. They’re limitations baked into how legacy systems were built.

A Shift in What Technology Enables

What’s changed—and what I told that Minnesota lender—is that we don’t have to approach data this way anymore. Modern platforms are built to handle data as it actually exists.

Not perfectly structured. Not fully aligned. But real. Thanks to advances in data normalization and automation, systems can now:

  • Ingest inconsistent parcel data from multiple sources
  • Standardize formats automatically
  • Continuously validate and refine data over time

That changes the role of conversion entirely. In fact, we’ve changed our whole approach—we don’t even call them conversion files anymore. We call them ‘Welcome Files!’

Conversion Simplified to a ‘Welcome File,’ Not a Project.

With the right real estate tax partner, the biggest psychological barriers to change just melt away.

If you don’t have to stop everything to clean your data… If you don’t have to get everything perfect before you start… If the intelligent system can improve data as you use it……then modernization becomes possible without the disruption. That’s the shift.

Conversion no longer needs to be:

  • A massive upfront effort
  • A high-risk transition
  • A drain on internal resources

It can happen with experts working right alongside your operations team to confirm the data and make sure the results are accurate.

Building Systems That Keep Data Clean

Solving conversion is only half the battle. The next question that lender asked was exactly the right one:

“How do we make sure we don’t end up back here again?”

Because keeping data clean over time matters just as much as cleaning it up in the first place.

This is where system design really matters—and it’s what I’ve spent my whole career building: intuitive, smart systems that work with the user instead of against them. Modern platforms embed data integrity directly into the workflow:

  • Data is validated at the point of entry or ingestion
  • Inconsistencies are flagged immediately—not weeks later
  • Standardization rules are applied automatically
  • Updates happen in real time across the system

Instead of leaning on periodic cleanup, the system keeps the data clean on its own, all the time. That reduces the need for:

  • Manual reconciliation
  • Visual cross-checking
  • End-of-cycle corrections

And it frees up operations teams to focus on the exceptions—not everything.

Where Operations and Data Come Together

What became clear in that conversation—and in plenty of others like it—is that data and operations are joined at the hip.

When data is fragmented, operations become reactive. When data is inconsistent, processes become manual. When data isn’t trusted, teams create workarounds.

But when data is:

  • Centralized
  • Continuously validated
  • Aligned across workflows

Operations simplify naturally.

This shows up most clearly in areas like:

  • Delinquency tracking, where status is consistently updated
  • Escrow management, where amounts reflect real-time data
  • Payment execution, where actions are based on validated information

The work doesn’t just get faster. It gets easier—and a whole lot more reliable.

A Personal Reflection

That conversation with the Minnesota lender has stuck with me.

Not because their challenges were unique—but because they stood in for so many others.

Strong teams. Well-built processes. But an operating model that required too much effort to maintain.