How do I evaluate an ERP vendor's API without a trial system?

Read the public documentation first: if it is not public, that is already an answer. Then check three things — whether write operations exist for the objects you care about or only reads, whether there is a rate limit and what it is, and whether the docs show authentication with real examples. A vendor that publishes an OpenAPI spec and a sandbox is in a different category from one that sends a PDF.

Is SOC 2 enough for vendor security due diligence?

It is the baseline, not the finish line. A SOC 2 Type II report tells you controls were tested over a period, but the scope is defined by the vendor — read which trust criteria were included and whether the systems in scope are the ones you will use. For regulated data add the sector-specific requirements: HIPAA business associate agreements for healthcare, PCI DSS scope questions wherever card data touches the system.

Should we build integrations point-to-point or use an iPaaS?

Point-to-point is faster for two or three integrations and becomes a maintenance problem somewhere around six. An integration platform costs money and a learning curve but centralizes error handling, retries and monitoring — which is what you actually spend your time on once integrations are live. If you already run one for other systems, extend it rather than starting a second pattern.

How much customization is too much?

The practical test is the upgrade: if applying a vendor release requires regression-testing custom code, every future update carries a project cost. Configuration inside the vendor's supported extension framework is usually safe. Modified core objects are the ones that strand companies on old versions — most of the systems in our legacy category got there this way.

ERP for IT Leaders — Architecture, Integration, Operations

IT usually inherits an ERP decision that was made on functional grounds and then has to live with its architecture for a decade. The leverage point is early: a handful of technical questions answered during selection determine whether the next ten years involve routine updates or a slow accumulation of things nobody dares touch.

The deployment question, without the marketing

"Cloud" covers at least three different things, and the differences matter operationally. Multi-tenant SaaS means the vendor updates everyone on their schedule — you get security patches without effort and lose control over timing. Single-tenant hosted gives you version control and puts the infrastructure burden on a partner. On-premises keeps everything in your hands, including the patching backlog.

Of the 302 products in our directory, 131 are cloud-only, 163 offer both, and eight have no true SaaS option at all. So the choice genuinely exists — but it narrows fast once you filter for a specific industry. The deployment comparison works through the trade-offs; the operational summary is that SaaS trades control for a smaller run-team, and that trade is usually right for companies without a dedicated infrastructure group.

Integration: ask these before signing

Integration is where ERP projects quietly exceed their budgets, and the questions that predict it are answerable during evaluation.

Is there a documented REST API covering the objects you need — and does it support writes, not just reads? Are there API-first guarantees, or is the API a partial afterthought over a legacy core? Are there webhooks for events, or will you be polling on a timer? What are the rate limits, and do they apply per tenant or per endpoint? Is there a sandbox, and does it cost extra?

For anything beyond a handful of connections, consider whether an iPaaS layer belongs in the architecture. It adds cost and a dependency, and it gives you one place where retries, error queues and monitoring live — which is worth a great deal at 3 a.m. on a close weekend.

Identity, access and the audit conversation

Single sign-on should be non-negotiable and frequently is not: some mid-market systems charge for SAML or OIDC support as an enterprise-tier feature. Confirm it early, along with SCIM provisioning if you want joiners and leavers handled automatically rather than by ticket.

The permission model deserves a demo of its own. What you are looking for is whether roles can express segregation of duties at the granularity finance will need — the person who creates a vendor cannot also approve payment to it — and whether the audit trail is tamper-evident. SOC 2 reports cover the vendor's own controls; they say nothing about how you configure yours.

What the upgrade path actually looks like

Ask what happens to your customizations when a release ships. In SaaS the answer is that extensions in the supported framework survive and modified core objects do not exist. In on-premises deployments the answer is a project, and the length of that project is the real cost of the customizations you agreed to during implementation.

This is the mechanism behind most of the systems in our legacy category. None of them failed technically. They accumulated modifications until upgrading became a re-implementation, and then stayed put — some for fifteen years, still running the business, still one retirement away from having nobody who understands the customizations.

Operations after go-live

Budget for the parts that do not appear in the license quote: monitoring and alerting, a backup and restore procedure you have actually tested, an integration error queue with an owner, a sandbox refresh routine, and enough documentation that a new hire can find the interfaces. On SaaS, add release-note review as a standing task — vendor updates arrive whether or not you read the notes, and the ones that change behavior rarely announce themselves loudly.