Rebuilding your EMF processes in something you can actually maintain

Here's the conversation I have a lot. A company runs some number of EMF processes inside Ross — the automations that quietly move data, trigger events, and hold parts of the operation together. They mostly work. But the person who built them is gone, or retired, or exists only as a name on old documentation. Every change is a small act of courage. And when the company tries to hire someone who knows EMF, the search returns roughly nobody.

That's the real situation, and I want to name it precisely, because the usual framing is wrong. EMF's problem usually isn't that it doesn't work. It's that almost no one left can safely change it. The fix isn't to rip out something that's functioning — it's to move those automations into tooling your team can see, edit, and hire for. Modern tools like n8n, or a straightforward full-stack build, can carry the same work in the daylight.

First, credit where it's due

I'm not here to trash EMF. It solved real problems for a long time, and a lot of Ross shops leaned on it because it could do things the base system couldn't. If your EMF processes are running today, they're running because someone understood the business and encoded it, and that work has been paying rent for years. Dismissing it as "legacy junk" is both rude and inaccurate, and it usually comes from someone who couldn't build it themselves.

So the case for change isn't that EMF is bad. It's narrower and more honest than that.

The real risk is the bus factor

The problem with EMF in 2026 is not technical. It's actuarial.

The pool of people who can confidently work in EMF is small and shrinking, the same way the Ross bench overall is thinning as people retire or move to Oracle and SAP work. When your automations live in a tool that almost nobody understands, and the one person who did has moved on, you don't have software — you have a relic you're afraid to touch. Every change becomes a risk assessment. Improvements don't get made because nobody's sure what they'll break. And the day something does break, you're not debugging, you're doing archaeology.

That's the actual exposure: not that EMF fails, but that it's become unmaintainable and unhireable-for. A process you can't safely change is a process slowly turning into a liability, no matter how well it runs today.

Rescue or replace — and how to tell

There are two legitimate responses, and I do both, so I have no incentive to push you toward the wrong one.

Rescue is right when the EMF process is doing something valuable and stable, and you mostly need someone who can actually read it — to document it, fix the one thing that's wrong, or make a careful change. I still speak EMF. If you need the black box opened and explained rather than replaced, that's a real service and it's rarer than it should be.

Replace is right when the process needs to keep evolving, when the maintainability risk is real, or when you're modernizing the surrounding stack anyway and this is one more thing that shouldn't stay trapped. The trigger for replacing isn't fashion or a dislike of old tools — it's maintainability and risk. If you can change it safely and it doesn't need to grow, leave it alone. If you can't, that's your answer.

The honest version of this advice is that most shops need some of each: rescue the handful of processes that are fine as they are, rebuild the ones that keep needing changes or keep scaring everyone.

What you gain by rebuilding

When you do move an automation out of EMF and into something like n8n or a full-stack service, the wins are concrete.

You get visibility — you can see what the automation is actually doing, step by step, instead of trusting a black box and hoping. You get maintainability — changes are a normal task, not a held-breath event, because the tool is legible and the logic is explicit. You get a labor market that exists — n8n and standard web development are things you can hire for, train on, and get help with, which EMF is very much not. And you get easier hooks for everything modern, AI included, because an automation built in current tooling is trivially easy to extend, and an EMF process is trivially easy to break.

None of that requires giving up the behavior you depend on. It's the same automation, doing the same job, in a place where a normal team can live with it.

A migration that doesn't gamble

The way you do this without betting the operation is boring and deliberate, which is exactly what you want from anything touching a system of record. You go process by process, not all at once. For each one, you establish what it actually does — often the first time that's been written down since the original author left — then rebuild it in modern tooling and run the two in parallel until the new version demonstrably matches the old. Only then do you retire the EMF version. Prove parity, then cut over. The black box gets dismantled one well-understood piece at a time, and at no point are you flying blind.

The bottom line

EMF isn't the enemy, and neither is a rewrite for its own sake. The thing to fix is the risk you've quietly accumulated: automations that work but that no one on your team can safely change or replace. Rescue the ones worth keeping as-is, rebuild the ones that need to keep moving, and put the important stuff somewhere your team can actually maintain it. I still speak EMF. I just don't think you should have to live inside it.

Sitting on EMF processes nobody dares touch? I can read them, rescue them, or rebuild them in something your team can maintain — whichever actually fits. Let's talk →. Related: modernizing Ross ERP in 2026.