Legacy ERP in the AI era: software should adapt to you

Revised September 6, 2026: why AI changes the build-versus-buy decision, the scope of the Legbi migration and the operating options.

Your business should not have to fit the limits of software that was not built for it. If your ERP needs parallel spreadsheets, your SaaS charges for modules you never use and an important change depends on a vendor's priorities, it is worth questioning the arrangement: why is your company still adapting to the tool?

For a long time, the answer was that building your own cost too much. AI has changed that calculation. AI-assisted development creates an opening to reconsider purpose-built systems previously ruled out by budget or delivery capacity. Your choice no longer has to stop at accepting the legacy system or buying another tool with similar constraints.

You can build around your processes, connect your data and decide what improves first. And you do not need to become a technology company to do it: FMKTech builds and runs the system; you stay in control.

What AI changed about building versus buying

There are two distinct changes, and both matter to a software buyer.

AI to build the software

Coding agents can help implement features, write tests, investigate existing code and prepare integrations. With engineering direction and review, that creates room to explore solutions previously pushed aside by more urgent work.

In its 2026 Agentic Coding Trends Report, Anthropic reports that some AI-assisted work in its teams included tools and experiments that would not otherwise have been attempted. The report also emphasizes human supervision and validation. This is a reason to revisit the economics, not a guarantee of delivery speed or savings for every project.

Our commercial interpretation is straightforward: do not rule out purpose-built software based on what it cost to build five years ago. Assess the workflow you actually need against what is possible today.

AI inside your operation

The second change is what the system can do. Instead of only recording and displaying data, a solution can use AI to interpret documents, prepare analysis and route work according to your business rules.

For example, a purpose-built workflow could extract information from a document, cross-check it against operational data, flag discrepancies and send a proposed action for approval. That takes integration, permissions, evaluation and exception handling, not just a chatbot beside the ERP. Important actions remain subject to the controls defined for the business.

You do not need AI everywhere. Use it where it solves a problem; keep deterministic rules where precision and predictability are the requirement.

Stop renting limitations: a business decision

The Kill My SaaS movement captures the frustration of paying for generic software the customer cannot adapt. The event proposes testing open, customizable alternatives. For us, the point is not to promise a production ERP in a weekend. It is to put a question back on the table: why keep paying for something that does not meet your operational needs?

The goal is not to copy every screen a vendor ships. It is to replace the constraints that cost time, create dependency and prevent your company from working better. Your differentiator might be a simpler approval, customer service connected to the right data or a business rule a generic product will never prioritize.

When you control the software, you can prioritize those changes without waiting for them to make sense for a SaaS vendor's entire customer base. Competitive advantage comes from what your operation can do with it, not just owning the code.

From legacy operations to purpose-built software: Legbi

For Legbi, we migrated the legacy ERP and the entire operation previously run on legacy spreadsheets into purpose-built software for law firms, alongside legal AI capabilities.

This is why the assessment should look beyond the ERP license. The rules, data and workflows living in spreadsheets are also part of the operation that needs to move forward. In Legbi, the migration addressed both.

Choose what to replace first

Having an alternative does not mean replacing everything at once. The scope can include an entire ERP and the operation running on spreadsheets, as in Legbi, or start with a bounded workflow. The decision should follow what your company needs to gain, preserve and keep running during the transition.

A useful first scope describes a task your team recognizes from beginning to end: who starts it, which data it needs, who approves it, where it ends and what happens when something fails.

Before estimating the build, record:

• Current problem: where rework, waiting and parallel controls occur.
• Delivery boundary: what changes now and what stays in the existing system.
• Dependencies: integrations, data access, the ERP vendor and the availability of people who validate the work.
• Acceptance criteria: a real operation that must work, including its exceptions.
• Baseline: execution time, errors or manual work before the change.

“Build a new module” is still vague. “Let the team complete this workflow, with these permissions and these reconciled data” is a scope that can be tested.

Migration is a deliverable of its own

A new screen does not, by itself, solve historical data or coexistence with the ERP.

Define which system is authoritative for each piece of information during the transition. Plan how to extract, transform and reconcile data, who approves discrepancies, and how to prevent two tools from updating the same record incompatibly.

A production cutover needs rehearsal, go/no-go criteria and a recovery plan. Building with AI does not remove that responsibility to the live operation. Our engineering guide to existing systems goes deeper into coexistence, validation and reversibility.

Who controls the code, data and operation?

Put these answers in the proposal and contract before development begins.

Confirm who gets access to the repository, infrastructure, third-party accounts and documentation. Define rights to the code, terms for external components and how to export data in a usable format. A copy of the repository is not enough if nobody can deploy or operate the system.

Knowledge transfer needs a scope too: who will be trained, which procedures will be handed over and how another team could take over maintenance. The goal is operational independence, not just a collection of files.

We run it. You stay in control.

You do not need an in-house infrastructure team. FMKTech offers managed operations: deployment, hosting, monitoring, backups, maintenance and ongoing support, with scope and costs agreed in the proposal. If you prefer to operate with your team or another partner, we provide access, documentation and a practical handover. Operating the software yourself is an option, not a requirement.

Agree how incidents are reported, who investigates, which hours are covered, and what counts as a fix versus a product enhancement. Dependency updates, monitoring, backups and restoration tests need named owners.

If the system uses AI, include response evaluation, access controls and failure handling. An agent should not receive permission to change important data simply because it can answer questions about them.

Compare the full cost

Compare options over the same period of use. On one side: licenses, integrations, support and manual work that will remain. On the other: the build, migration, infrastructure, maintenance, operation and future changes.

FMKTech's proposal makes the scope and costs of managed operations explicit, including hosting, AI usage and third-party services where applicable. You compare a working solution against what you pay for and work around today, not a subscription against an abandoned repository.

Check which licenses can actually be retired. An integration can improve the work without eliminating the ERP. Owning software does not guarantee savings: the comparison needs to include both costs and the capabilities your business gains. Record a baseline and verify the outcome after the change.

Which limitation can you stop accepting?

Bring the system that most limits your team and the workflow it should handle. The tools involved, a sample without sensitive data and your operational constraints help define the way out.

Our SaaS Exit Plan turns that assessment into a scoped engagement: choose what to retire, design the system around your operation, plan the migration and define how we will keep it running. FMKTech can handle the build and operations; taking over with your team or another partner remains an option.

You do not have to keep renting limitations. Talk with us about software built for your operation.