We have decided to leave Epicor Cloud and transition back to a self-hosted environment. I’m curious if anyone else has gone through this process, as it seems like a straightforward data migration after a new installation. I would love to hear any lessons learned or things to avoid during this transition.
Can you share how you convinced epicor to let you out of the contract and take back your perpetual licenses?

We did 8 years ago. I was still in the “fake it till you make it” stage of my Epicor career arc, so I don’t know how much help I’d be there. A consultant held my hand.
But, no it wasn’t much at all. We were MT SaaS, so we had to back up all of our Char01 fields (in Excel) and if we kept them, we created proper UD fields to store that data and DMT back in. Of course that affects any BAQs and BPMs, etc.
I don’t know if they still do the Char01 business anymore or if you had bona fide UD fields already.
That’s the only thing that I recall.
Oh, and I deliberately gave everyone new user IDs. NOT a requirement, but I hated the IDs being 12345-ZSmith, so I made everyone start anew with just ZSmith.
We were only 7 months into the implementation, so no one noticed.
I’d like to know this too. I attempted to get this started as was told by my Cam that there is no way to do this and they can’t help.
I would imagine Epicor can give you a copy of your DB that you can then load onto your on-prem sql server… too easy???
That’s what I assumed. They said that SAAS is in a monolithic DB and they can’t separate our data out.
![]()
We are still working through the nitty gritty details, and of course when I asked for the migration guide, they sent me through the link of the new installation setup guide.
The contract terms are not my thing, I leave that to the folks upstairs. I am just a lowly Epicor Admin.
Really? That’s not how I thought they were deploying cloud based on how it’s talked about. Thought everyone maintained their own dB in Azure on a SQL Server.
There are old MT setups that are this way. New normal SaaS you do get your own Db but MT was shared ![]()
![]()
Well, getting the licenses is the hard part. Moving the database (assuming you are public cloud) is easy just like any other server migration.
It’s inexplicably common. The first time I saw this, I assumed it had to be the last act of some disgruntled employee lighting a fuse on their way out. What a way to go, sure hope they have solid legal help on retainer, I thought to myself.
After seeing this in the wild like eleventy billion times, now I have to assume some developers have managed to believe it’s a good idea?

Yeah it works well in theory for very small vanilla companies. Epicor isolates / separates that context fairly well. But yeah restoring yourself or pulling yourself out of there would require a full implementation and a manual data migration.
I’m missing something in all of the naysaying here. We were MT SaaS and we left it to go on prem and it was seamless.
Again, it was early in our journey, but the database is the database. Restore from backup. What am I missing?
I’d be more willing to act like I had no clue if we hadn’t actually done this.
Tangent thought - if SaaS stores your file attachments, you’ll need to get those, too.
With Multi-Tenant, there is one database. Each company shared tables and data was separated by Company Id. A simple backup and restore would include data from all companies. This is why BPMs didn’t allow code because the DbContext would allow access to other companies’ data. MT was a hold over from Epicor Express, designed for smaller companies, and is as about as old as Azure.
Hopefully the statute of limitations has passed by now, but there was a secret hack some of us used to deploy code in MT… If you imported a code bpm developed in a different environment it worked ![]()
Well somehow they figured out how to put just our portion of it on an FTP server so we could download it.
5 GB back then.
We are close to 300 GB now.
Which is why they invented Dedicated Tenant!