Life After Launch: Maintaining and Evolving Your ERP Interface Layer

Go-live is a milestone worth celebrating. After weeks of discovery, design, development, and testing, your ERP interface layer is finally live. Your team has a modern front-end. Your customers can self-serve. Your managers have real-time dashboards.

But here is the truth that nobody in the ERP world likes to say out loud: go-live is not the end. It is the beginning.

The real value of an interface layer reveals itself over months and years, not days. It comes from how the platform is maintained, how it adapts to changes in your underlying ERP, how it evolves with your business, and how the relationship with your implementation partner works in practice.

This article covers everything that happens after your Sysgraft interface layer goes live. What the subscription covers. How we handle ERP API updates. How you measure success. How new features get built. What happens if you want to change hosting. What happens if you want to leave. The questions most people forget to ask until after they have signed.

What the Monthly Subscription Actually Covers

When you sign up for a Sysgraft interface layer, you pay two things: a fixed build fee to create the platform, and a monthly subscription to keep it running. The build fee is straightforward. The subscription is where most of the questions come in, so let us be precise about what it includes.

Hosting infrastructure. Your interface layer runs on dedicated cloud infrastructure — typically AWS London (eu-west-2) or Azure UK South, depending on your preference. This includes the application server, a managed PostgreSQL database for session and caching data, a Redis cluster for API response caching, and a CDN for static assets. We manage all of it. You never see an AWS bill.

Security patching and updates. Every dependency in the stack — the Node.js runtime, the Next.js framework, every npm package, the OS-level container images — is monitored for CVEs and patched on a rolling basis. Critical patches are applied within 48 hours. Routine patches are bundled into monthly release cycles.

Performance monitoring. We run 24/7 application performance monitoring (APM) across the entire stack. We track API response times, page load metrics, error rates, and availability. If something goes wrong — a slow BC API endpoint, a spike in error rates, a database connection pool that is exhausting — we know before you do. Alarms fire to our engineering team on-call.

Availability SLA. The platform targets 99.5% uptime, measured monthly. This covers the interface layer itself (not BC, which is your Microsoft SLA). If we drop below 99.5%, you receive a service credit proportional to the shortfall.

Support. You get access to a dedicated support channel (typically Slack or email). Severity 1 issues — platform down, users cannot log in — get a response within 2 hours during business hours. Severity 2 issues — feature degraded but usable — within 8 hours. There is no per-incident charge, no ticket cap, no support tiers. Every customer gets the same engineering team.

Feature evolution. The subscription includes a budget for ongoing feature development — typically 4 to 8 days per month, depending on your plan tier. This is how the platform grows with your business. More on that in section five.

What the subscription does not cover: changes to your Business Central configuration or data, changes to your Microsoft licensing, or training for new staff beyond initial onboarding. Those remain your responsibility, as they should be.

How ERP API Updates Are Handled

Your ERP vendor releases updates. That is a fact of life. Microsoft ships two major updates per year for Dynamics 365 Business Central (wave 1 in April, wave 2 in October). Sage releases periodic updates. OrderWise, Epicor, and every other ERP vendor has their own cadence.

The question is: what happens to your interface layer when the ERP changes?

The answer depends on the type of change.

API version bumps. Your ERP’s REST API is versioned. When the vendor releases a new API version, the old version typically has a deprecation window — usually 12 to 24 months. We monitor every vendor’s release notes, developer blogs, and partner communications. When a deprecation is announced, we schedule the adapter update into our regular maintenance cycle. The actual migration is usually a matter of adjusting the API client configuration and running the test suite.

Schema changes. Sometimes a vendor adds, removes, or renames fields on an existing API endpoint. These are usually backwards-compatible for reads (the old fields remain available during a transition period), but can break write operations. Our adapter layer handles this by decoupling the internal data model from the API schema. When a field changes, we update the mapping in the adapter. The frontend components do not change.

New endpoints. When your ERP vendor adds new API endpoints — for example, a new inventory valuation endpoint or a new shipping integration — those become available for your interface layer to consume. If the new endpoint adds value for your workflows, we can incorporate it into a feature evolution cycle. If not, there is no pressure to upgrade.

Non-API changes. Some ERP updates touch the user interface or business logic without changing the API surface. These do not affect your interface layer at all. Your custom frontend continues to work exactly as before.

Graceful degradation. In the rare case that an ERP API change breaks a specific feature before we have had a chance to update it, the platform degrades gracefully rather than crashing entirely. That feature shows a clear “currently unavailable” message. The rest of the platform continues working. We log the error, investigate the root cause, and deploy a fix within the SLA window.

The key architectural principle here is the adapter layer. Because all ERP communication goes through a single, isolated adapter, changes to the ERP never ripple through the entire application. You get the stability of a monolithic backend with the flexibility of a microservices architecture.

Measuring Success: The Metrics That Matter

You did not build an interface layer for the sake of it. You built it to achieve specific outcomes: faster workflows, fewer support calls, better data access, happier users. But how do you know whether it is actually working?

We recommend tracking five categories of metrics after go-live.

Adoption rate. The simplest measure is raw usage. How many of your staff log in each day? What percentage of customer accounts have logged into the portal? Are adoption rates growing or plateauing? We surface this data in a built-in usage dashboard that shows active users, session counts, and feature usage heatmaps. If adoption is low, we work with you to understand why — training gaps, missing features, UX friction — and address it in the evolution cycle.

Call reduction. If you built a customer self-service portal, the single most valuable metric is the reduction in inbound calls and emails about order status, invoice queries, and stock availability. Track your support ticket volume before and after launch. A well-designed portal typically reduces order-status-related calls by 60–80%. That is not just a cost saving; it means your sales and support teams can focus on complex enquiries that actually need human judgement.

Time savings. Measure the time it takes your staff to complete common tasks before and after the interface layer. How many seconds to look up a customer order? How many clicks to create a sales order? How long to check stock availability? We capture baseline metrics during the discovery sprint and measure against them quarterly. Typical results: task completion time drops by 40–70% for the workflows that the interface layer targets.

User satisfaction. Run a simple anonymous survey three months after go-live. Ask your team: “On a scale of 1 to 10, how much has the new interface improved your day-to-day work?” And “Would you want to go back to the old system?” The second question is surprisingly revealing. We have never had a team say they preferred the old ERP UI.

Business outcomes. The hardest metrics to measure directly, but the ones that matter most. Has your order-to-cash cycle improved? Are customers paying invoices faster because they can see them online? Are you winning more business because your customer portal differentiates you from competitors? These lagging indicators take 6–12 months to become visible, but they are the ultimate measure of ROI.

Feature Evolution: How the Platform Grows

Your business does not stand still. Neither should your interface layer.

New features are prioritised through a structured but lightweight process. Every customer gets a shared backlog where you can submit feature requests, vote on priorities, and see what is scheduled. We review the backlog with you every month during a 30-minute check-in call.

Prioritisation factors:

• User impact. How many people will this feature help? A feature that saves 50 people 2 minutes per day has a higher impact than a feature that saves 2 people 10 minutes per day.
• Business value. Does this feature directly support a business goal — reducing support costs, accelerating order processing, improving customer retention?
• Implementation complexity. Is this a simple UI change that can be done in two days, or a multi-week project requiring new API integrations?
• Strategic alignment. Does this feature move the platform towards the longer-term vision you have for your digital operations?

Scoping and building: Once a feature is prioritised, we scope it in a lightweight spec document: what it does, how it works, which screens change, what the acceptance criteria are. You review and approve before any build starts. Small features (1–3 days) are bundled into monthly release cycles. Larger features are planned as separate projects with their own timeline and budget. Because your subscription includes a monthly development allowance, smaller features are usually covered without additional cost.

We also track feature usage after release. If nobody uses a new feature after 90 days, we flag it in the monthly review. Sometimes features need better onboarding or a UX tweak. Sometimes the idea was not as valuable as expected. The important thing is that we close the loop: built, launched, measured, learned.

What You Can Do Yourself

One of the most common questions we hear is: “Once the platform is built, how much control do we have?”

The answer is: as much as you want. You own the code from the moment of go-live. Every line of TypeScript, every React component, every API adapter, every deployment script — it is all your intellectual property. There is no proprietary framework, no black box, no “you need a licence to edit this.”

If you have an internal development team, they can make changes directly. They can add new pages, modify existing workflows, connect additional data sources, or customise the branding. The codebase is a standard Next.js + TypeScript project with a well-documented architecture. Any competent React developer can pick it up.

If you want to make changes but prefer us to handle the build, that is what the subscription covers. If you want a mix — your team handles minor UI tweaks, we handle API integrations and infrastructure — that works too. We have customers in all three configurations.

The important thing is that nothing locks you in. The code is yours. The data is yours. You are never dependent on Sysgraft to make a change to your own platform.

What Happens If You Want to Switch Hosting

Our standard subscription includes hosting on our managed infrastructure. But circumstances change. Perhaps your organisation has a policy requiring all applications to run on your own AWS account. Perhaps you already have existing infrastructure that you want to consolidate onto. Perhaps you simply prefer to manage it yourself.

Self-hosting is a supported option. We provide a complete deployment package: Docker images for the application, Terraform scripts for the infrastructure, environment variable templates, monitoring configuration, and a runbook explaining how to operate it. Your team spins it up on their own AWS, Azure, or GCP account.

What changes: you take over the hosting cost and operational responsibility. You handle your own security patching, scaling, and incident response. You no longer pay the hosting component of the subscription.

What does not change: we still provide support for the application code. If you find a bug in the interface layer or need help understanding the architecture, we are available under a reduced support retainer. We also continue to monitor the ERP API for breaking changes and provide adapter updates — because those updates protect the codebase you own.

Migration is a straightforward process. We have done it twice, and both migrations took less than a week from decision to fully operational.

What Happens If You Want to Cancel

This is the question that separates honest partners from the rest. Anybody can talk about how good the service is. The real test is how easy it is to leave.

Our standard subscription has a 12-month minimum term. After that, it rolls month-to-month with 30 days’ notice. If you decide to cancel, here is exactly what happens.

Notice period: 30 days from the date you notify us. During this period, the platform continues to run normally. We do not switch anything off early.

Code handover: On your notice date, we prepare a complete handover package. This includes the full source code (from the git repository), all documentation (architecture overview, deployment guide, API adapter documentation, and release history), and the database schema and migration scripts. We hand this over on the last day of the notice period, or earlier if you prefer. There is no additional charge for the handover.

Data export: The interface layer stores very little persistent data — mostly session caches and configuration. The vast majority of your data lives in your ERP. We export everything in a standard format (CSV or JSON) and provide it alongside the code handover.

Infrastructure teardown: After the handover is complete, we decommission the hosting infrastructure. By default, we retain backups for 90 days in case you need to recover anything. If you want us to destroy everything immediately, you can instruct us to do so.

What you walk away with: A fully functional codebase and the knowledge to run it yourself or have another development team take it over. If you decide to move to a different provider or bring development in-house, the code is immediately usable. There is no migration period, no data transfer, no re-platforming needed.

We have never had a customer cancel. But we designed the handover process as if every customer might. It keeps us honest.

Long-Term Support: Keeping the Platform Current

Technology moves fast. Frameworks evolve. Security standards change. Compliance requirements shift. A platform that is unmaintained for two years becomes a liability.

Our long-term support model is designed to keep your interface layer current across three dimensions.

Framework and runtime updates. We track the Next.js and React release cycles. When a new major version ships, we plan the migration into the maintenance cycle. These migrations are transparent to you — the user experience does not change, but the underlying code gets the performance improvements, security fixes, and new capabilities of the latest framework version.

Security posture. Beyond CVE patching, we conduct quarterly security reviews of the platform. This includes dependency scanning, penetration testing of the authentication flows, and a review of the infrastructure security configuration. Any findings are addressed in the next release cycle.

Compliance. If your industry or regulatory environment changes — new data protection requirements, accessibility standards, or reporting obligations — we can adjust the platform to comply. GDPR compliance, WCAG accessibility standards, and SOC 2 or ISO 27001 alignment are all within scope.

Technology evolution. Sometimes a genuinely new technology changes what is possible for ERP interfaces. AI-assisted data entry, natural language querying of ERP data, real-time collaborative workflows — these are not futuristic concepts, they are capabilities that are becoming practical today. Our platform is built on a modern stack precisely so that these capabilities can be added when they make sense for your business, without needing to rebuild from scratch.

The goal is not to keep changing the platform for the sake of change. The goal is to make sure that in three years’ time, your interface layer does not feel outdated — that it continues to be a competitive advantage rather than a technical debt.

---

Frequently Asked Questions

---