---
type: concept
title: 'ERP App Readiness: SuiteApp & Business Central'
aliases:
  - ERP readiness
  - SuiteApp readiness
  - Business Central readiness
  - what it takes to ship a SuiteApp
  - dual-ERP app readiness
modified: 2026-06-14
tags:
  - netsuite
  - business-central
  - dynamics
  - suiteapp
  - readiness
  - squire
  - technical-proof
  - differentiation
---

# ERP App Readiness: SuiteApp & Business Central

> What it would actually take for SuiteCentral to run *inside* the ERP — as a NetSuite SuiteApp and as a Business Central AL extension — separating what already exists from the net-new engineering, and where Squire's own expertise changes the calculus.

## What this page is

A pair of partner-facing readiness briefs, captured as wiki concepts. Together they answer "could this be a real ERP-native app?" honestly — distinguishing the marketing-loose sense of "SuiteApp" from the real engineering project, and naming the three readiness tiers that the earlier evaluations under-stated. Full captures: [[sources/34-netsuite-suiteapp-readiness|NetSuite SuiteApp readiness]] and [[sources/35-businesscentral-dynamics-readiness|Business Central / Dynamics readiness]].

## The three tiers (both ERPs sit at the same place)

There are **three** tiers hiding inside "make it an ERP app," not two:

1. **Integrates with** (SDN listing / BC ISV integration) — external app, API-connected, listed as verified. **Status: close** — mostly the production-tier live-credential test (V3 for NetSuite; its analogue for BC) plus partnership paperwork.
2. **Embedded host** (NetSuite host Suitelet / BC AL page-extension + control add-in) — renders the product *inside* the ERP UI via a secure, account-agnostic, token-safe bootstrap. **Status: built & tested** for both ERPs, proof-carded (`embedded-platform-adapters`). Remaining: a first real install with recorded evidence (overlaps a pilot).
3. **Full native app** (in-account SuiteScript / full AL on AppSource) — the product's logic runs in-account. **Status: a real project, not started** — gated on an architecture split decision (how much runs in-ERP vs. external) plus marketplace technical-standard conformance (Oracle BFN / Microsoft AppSource).

## NetSuite ↔ Business Central parity

The platform did the same hard architectural work for both: a production connector and a secure embed host. `BusinessCentralConnector` is one of the 5 production connectors; the BC AL extension mirrors the NetSuite Suitelet's hardening (https-only token transport, origin allowlisting against `*.dynamics.com`, no leaky bodies). This makes the product **credibly dual-ERP, not NetSuite-locked**.

**Broader Dynamics 365** (Finance & Operations / Dataverse) is a *different, lower* readiness level — demo-only connector, no embed host — and is out of scope until a real opportunity justifies it.

## The Squire angle

A full native SuiteApp, if pursued, should be **Squire-led**: Squire builds SuiteApps already (PaymentCentral et al. live inside NetSuite), so the in-account packaging muscle, SDF tooling, SDN membership, and BFN-review experience are in-house. BC is newer territory for Squire (a NetSuite-centric consultancy), so BC parity is best positioned as a market-size/credibility point rather than the first investment.

## Recommendation in one line

Lead the pilot on NetSuite (Squire's home turf, where SyncCentral lives); the embedded-host work means a pilot needs **nothing further on the app-packaging axis** beyond the production-tier connector test. Defer the full native apps (both ERPs) until a pilot proves the value — and make the in-ERP-vs-external architecture decision deliberately at that point.

Related: [[pages/concepts/suitecentral-deployment-options|SuiteCentral 2.0 Deployment Options]], [[pages/concepts/production-vs-demo|Production vs Demo: What's Real]].