For the past year, I’ve been working on something that sounds simple when you describe it in one sentence:

Migrating a Loan Origination System from ICE Encompass to Vesta.

Of course, anyone who has actually worked on a mortgage system knows that “migration” is one of those words that can mean anything from “copy some data over” to “question every architectural decision you have made for the last ten years.”

This one is definitely closer to the second category.

We were previously built around ICE Encompass, and our new platform is Vesta. Both are LOS platforms, both manage loans, borrowers, documents, workflows, and all the other wonderful things that make mortgage software what it is.

But once you start working with both systems every day, you realize that they have some very different ideas about how an LOS should work.

Here are a few differences that stood out to me during the migration.

Desktop vs. Browser

The first difference is probably the most obvious.

Our Encompass environment has traditionally been based on the desktop client. Vesta, on the other hand, is browser-based.

And yes, you can feel the difference.

Vesta feels lighter and more flexible. Open a browser, log in, and you are there. There is no traditional desktop application to install, maintain, update, or wonder why it suddenly decided that today was a good day to stop cooperating.

Encompass, by comparison, feels a little more heavyweight.

To be fair, ICE has also introduced a Web version of Encompass, so the future of Encompass is clearly moving in that direction. But our environment has been using the desktop client for a long time, so our day-to-day experience has mostly been with the traditional application.

And after years of working with it, you get used to it.

Until you switch to a browser-based LOS and suddenly realize that your browser has been waiting patiently to become your new LOS client all along.

The Loan Lock Problem

The more interesting difference is what happens when multiple people want to work on the same loan.

In Encompass, editing a loan generally involves locking the loan.

If one user has the loan locked for editing, another user can’t simply open it and start changing things.

This is a very understandable design.

A loan contains a huge amount of interconnected data. You don’t want User A and User B editing the same object at the same time and then discovering that whoever clicked Save last accidentally erased the other’s changes.

So Encompass basically says:

“One person at a time, please.”

It works.

But it also means that collaboration can become a little awkward.

Vesta takes a fundamentally different approach.

Because the Vesta client is designed around real-time persistence, changes are saved as they happen. There isn’t the same traditional “open → edit → save → unlock” workflow.

That means multiple people can work with the same loan without the traditional loan-locking model getting in the way.

Architecturally, I really like this idea.

But, as usual, solving one problem creates another.

The danger of the accidental change

If everything is saved immediately, you have to be much more careful about accidental edits.

Imagine that you are just looking at a loan.

You scroll through the page.

Your mouse wheel moves.

Your keyboard accidentally hits a key.

You click something you thought was just a selector.

And suddenly…

Congratulations. You changed the loan.

There is no comforting “Don’t worry, you haven’t saved yet” moment.

The change may already be persisted.

This is one of those interesting trade-offs in software design:

Traditional save-based systems protect you from some accidental changes, but make collaboration harder.

Real-time systems make collaboration much easier, but make accidental changes more dangerous.

Neither approach is universally better. They simply move the risk to different places.

Two Very Different Ideas About Data

The biggest difference I’ve noticed, though, isn’t the UI.

It’s the philosophy behind the data model.

Encompass is relatively permissive.

There are many fields that are related to each other. Change one field, and Encompass may automatically recalculate several others.

For example, changing one of the important loan or property values may cause things such as LTV, payment amounts, or other calculated values to change.

But here’s the interesting part:

The fact that a value is calculated doesn’t necessarily mean the user is forbidden from changing it.

In many situations, Encompass allows users to override calculated values.

And sometimes something even more interesting happens.

A field may appear to be read-only in the Encompass client, but the underlying platform may still allow it to be changed through the SDK or API.

In other words, the UI and the underlying data model don’t always enforce exactly the same rules.

From a developer’s perspective, this creates a surprisingly flexible environment.

The general philosophy feels something like:

“We’ll calculate this for you, but if you have a good reason to do something different, we’ll let you.”

That flexibility can be extremely useful in mortgage software.

Mortgage underwriting is full of exceptions. Not everything can be reduced to a clean mathematical formula.

Sometimes the system calculates something.

Then a human looks at the loan and says:

“Yes, but this particular loan is different.”

And the system needs to allow that.

Vesta Is Much Stricter

Vesta takes a very different approach.

If a field is automatically calculated, it is generally read-only.

And this isn’t just a UI rule.

This is the important part.

If the field is read-only in the Vesta UI, trying to modify it through an API may also fail.

In other words:

UI says: Read-only
        ↓
API says: Read-only
        ↓
Developer says: "But what if I really, really want to?"
        ↓
API: No.

And yes, I have learned to respect that “No.”

This makes Vesta’s data model much more strictly enforced.

From a system-design perspective, I actually think this is a very clean approach.

The system knows which values are derived and which values are inputs, and it tries hard to prevent developers from bypassing those rules.

But it also means that API integrations require much more careful planning.

You can’t simply look at a field, see that it exists, and assume:

“It’s an API field, so I can probably update it.”

Nope.

Before updating a field in Vesta, you need to understand:

Is this field calculated?
Is it writable?
What fields does it depend on?
Should I update another field instead?
Will Vesta recalculate this value automatically?
Is there a supported API operation for what I’m trying to accomplish?

Otherwise, your perfectly reasonable API call may come back with a perfectly unreasonable-looking error.

At least from the developer’s perspective.

Flexibility vs. Enforcement

This is probably the biggest philosophical difference I see between the two platforms.

Encompass tends to favor flexibility.

It gives users and integrations more freedom to manipulate the loan, even when the system has calculated a value.

Vesta tends to favor consistency and enforcement.

If the platform says a value is derived, it doesn’t want you changing that value directly.

You could summarize the philosophies like this:

	Encompass	Vesta
Client	Desktop in our environment	Browser
Editing model	Traditional loan locking	Real-time persistence
Collaboration	More restrictive	More flexible
Calculated fields	Often can be overridden	Generally read-only
API enforcement	Relatively permissive in some areas	Much stricter
Architecture	Mature / legacy-friendly	Modern / cloud-native

Neither approach is inherently right or wrong.

They simply make different trade-offs.

And those trade-offs become very obvious when you spend a year moving a real mortgage system from one platform to the other.

And Then There Is AI

There is one more area where Vesta has a very interesting advantage: AI.

Vesta was built with a much newer architecture, and AI is much more naturally integrated into the platform’s overall design.

The idea of having AI agents participate directly in loan workflows is particularly interesting.

That is quite different from simply adding an AI assistant to an existing LOS.

I haven’t personally used Vesta’s AI capabilities enough yet to give it a fair technical evaluation, so I’ll leave that topic for another post.

I would rather say “I haven’t used it enough to judge it” than write three paragraphs about AI based on a product demo and pretend I am now an AI expert.

The internet already has enough of those.

What I Learned from the Migration

After working with both platforms, one thing has become very clear to me:

An LOS is not just a collection of screens and APIs.

The platform’s philosophy shows up everywhere.

How does it handle concurrency?

How does it define a calculated field?

Who is allowed to change a value?

What happens when a user changes something?

What happens when an API changes something?

Where does the system enforce business rules?

And perhaps most importantly:

Does the platform trust the user, or does it trust its own data model?

Encompass and Vesta answer these questions differently.

Encompass gives you a lot of freedom. Sometimes that freedom is exactly what you need. Sometimes it means developers have to be very careful about what they change and how they change it.

Vesta gives you stronger guardrails. That can make the platform more predictable, but it also means you have to understand its rules before you start writing integrations.

After a year of migration work, I’ve learned that moving from one LOS to another isn’t really about moving data from System A to System B.

You’re also moving from one set of assumptions to another.

And sometimes, the hardest part isn’t figuring out how to call the new API.

It’s realizing that the new system has a completely different answer to the question:

“What should happen when someone changes a loan?”

Migrating from Encompass to Vesta: Two LOS, Two Very Different Philosophies