In 2026, the Epicor Classic Client will no longer be.

It will be an ex-UI.

If you’re running Kinetic on-premise, you obviously don’t need to panic, because you can choose when you upgrade to the point of classic not being supported. If you’re wise, though, you’ll be making plans even if you haven’t started already.

If you’re a SaaS user, you have a hard deadline. Any classic screens you’re still using are going to become unavailable, like it or not.

If you’re OK with that, skip straight to the how-to. (Yes, that’s a link.)

For the rest of us …

A moment of silence

I like the classic client. It’s still my preference, try as I might to get used to the new Kinetic client. It’s robust, proven, adaptable.

You can fit a lot more into a small space, and it’s clearer, generally, which screen you’re in. There are more developers, because it uses the same basic code and tools as the server side of Kinetic, and they’re Microsoft standard for the most part.

So I’m sorry to see it go. But here we are.

I come to bury the classic client, not to praise it. Some say it wasn’t ambitious, and that was a grievous fault.

The Kinetic UI is ambitious, and because it’s a massive step it’s been hardest to accept for those most familiar with the old client. It didn’t help that the ambition ran ahead of the reality for so long, meaning that users and admins got into the habit of retreating back to the familiar.

If you’re resisting change, this is for you.

It’s time to let go. The Kinetic client is good now, though I for one am not blind to some shortcomings, and you can do this.

You know it’s a big change, not a trivial one, so that gives you an advantage. It’s the users who think swapping out one set of screens for another is just an admin task are the ones who get bitten by the complexities they didn’t expect.

The Kinetic UI is completely different.

It’s different underneath, it’s different in the tools you use to modify it, and it’s completely different to use and look at.

Don’t let that blind you to what it can do, because you’re looking at what it isn’t. Arguably you can do more with it than the classic client. It can be great, and very flexible. The price you pay is not that you’re getting a lesser system, not in the least. It’s simply the sheer amount of change.

Vanilla Kinetic screens all look much the same, and nothing like users are used to. They take up far more space, and usually need more clicking.

DO NOT be tempted to try to get over that, and put them back how everybody will say they want. Yes, you could. Or make them even better. Don’t. This is a whole new UI, and users need to get used to it.

Treat this as a chance for a re-set.

A plan of action

1. Get users to use the new screens in the Kinetic UI.

If you’re doing a big upgrade from an older version, treat it as an implementation project, not an upgrade. Push users into a Dev system with all-new UI, and do scenario testing. If you’re already on a recent version of Kinetic, you can switch screens progressively, starting with ones that’ll matter less. If they’re using them live, it’ll be quicker finding out if anything needs adapting.

2. Make a list of the existing customised screens.

Do not start customising their replacements. Just make a list.

3. Divide the list into two types:

Trivial additions of non-standard data.
Anything else.

4. Check with users that they still need the non-standard data for each of the first set, and add it to a Kinetic version.

Treat those new customised screens the same as the completely standard ones. Either as part of the scenario testing or within the phased roll-out.

5. Deal with the second set, the more or less heavily customised screens.

Be prepared for additions to this list, if users find other Kinetic screens change in ways they can’t live with.

Actually customising those screens …

First of all, don’t. At least not yet.

Whether you’re doing a phased roll-out or a big upgrade, pull these out into a development system as a separate thing, and have a user seriously try the new base Kinetic screen with no customisation at all.

The new screens are so different that the thinking that led to the old customised screens probably won’t apply any more, so the old solution will be a bad guide to the new one. Take time to work with users to see how the Kinetic version works. Push back a bit, identify what the real gaps are, not what they expect them to be. There may be more, or there may be less, but they probably won’t be quite the same.

Then, finally, solve those problems.

But do it in a Kinetic-native way. If you try to duplicate what people have been used to in Classic, it’ll be headaches all the way, far more time, and won’t work as well. New thinking is required.

And, of course, Application Studio skills.

OK, what about that new thinking and those skills?

That’s another subject, for another post. If you can’t wait, feel free to get in touch.