Services
Two ways to engage
Both are scoped as fixed-fee, deliverable-based work — not open-ended hourly billing.
Not sure which one fits? Choose the Assessment if you're currently estimating or scoping a client upgrade and need to quantify integration risk before submitting a fixed-price bid. Choose Re-architecture Capacity if you already have a signed SOW and defined spec, but no available AL developer bandwidth to execute it.
Lead offer
Integration re-architecture capacity
For VARs with signed client SOWs needing immediate AL delivery capacity.
Contained, fixed-fee work items — migrating specific Dynamics NAV integration points to Business Central SaaS patterns — delivered directly into your repository, to your coding standards, against an agreed deliverable and acceptance criteria.
USD 6,000–12,000 per integration point · fixed fee, agreed before work starts
Invoiced in USD; EUR/GBP-equivalent invoicing available on request at the prevailing rate.
Representative pattern mapping
| Legacy NAV pattern | Target BC SaaS pattern |
|---|---|
| Direct SQL table access (external system reads/writes NAV tables) | BC API pages / OData v4 consumed by the external system |
| .NET interop assembly (NAV calling outward) | AL HttpClient + Azure Function / Logic App middleware |
| File-drop / polling job | Event-driven webhook or queue trigger |
| Hardcoded service credentials | OAuth 2.0 client-credentials flow |
Actual target pattern is confirmed per integration point during scoping — this table is representative, not a substitute for assessment.
How it works
- Pricing
- Fixed fee per deliverable — never hourly, never time-and-materials. A batch of related integration points is quoted as a single deliverable.
- Delivery
- Asynchronous. Work lands as commits/PRs in your repository, with core availability overlapping European afternoons through US Eastern mornings. No live meetings.
- Confidentiality
- NDA signed before any client- or codebase-specific detail is discussed.
- Attribution
- White-label. The work is delivered under your standards and your repository history — your end client is never made aware of a third party.
- Scope
- Defined per engagement: one integration point, or a batch of related ones, with explicit acceptance criteria agreed up front.
- Availability
- Currently booking 2–3 weeks out from signed scope. One engagement is taken at a time, so a start date is confirmed with the proposal rather than assumed.
Commercial terms
Non-circumvention
We never approach, solicit, or contract directly with your end client — during the engagement or after it. The relationship is with your practice, not your client.
Your margin
You set your own resale price to your client. What you pay us is never disclosed to them.
Payment on acceptance
Invoiced against the agreed acceptance criteria on delivery, not upfront — the risk of a deliverable falling short sits with us, not with you.
If acceptance fails
Revisions needed to meet the agreed acceptance criteria are included in the fixed fee, not billed separately.
Contracting
Engaged under your own standard contractor agreement, invoiced per deliverable — not a vendor-onboarding or supplier-portal relationship.
Data access
No production data access required. Work is performed against sandbox or anonymized data, which keeps client personal data out of scope entirely.
How async delivery works
Repository access
Work lands continuously in your repository as each piece is completed — via branch or pull request, in your private GitHub or Azure DevOps instance — not batched at the end. At any point in the engagement, everything delivered so far is already yours: committed, reviewable, and ready to hand to any AL developer to continue, with no dependency on us to retrieve work in progress.
Code quality
Deliverables are covered by AL Test Codeunits and checked against CodeCop, UICop, AppSourceCop, and PerTenantExtensionCop before handoff. Individual commits along the way — a config change, a refactor — may not each carry new tests.
IP ownership
100% white-label. Full IP transfers to your repository on delivery — no retained rights, no attribution.
VARs with recurring overflow can pre-book a fixed number of deliverables per quarter at an agreed price — pre-purchased, fixed-fee delivery capacity reserved in advance, not an on-call arrangement or a guarantee of same-day availability.
Secondary offer
NAV Integration Cloud-Readiness Assessment
For VARs scoping upcoming upgrades who need to quantify integration risk upfront.
A flat-fee, time-boxed assessment for a VAR that needs to understand the shape of a client's integration surface before committing to a migration project — or before scoping the work above.
What's delivered
USD 2,500–4,000 flat fee · 3–5 business day turnaround
Invoiced in USD; EUR/GBP-equivalent invoicing available on request at the prevailing rate.
A written findings document covering:
- Inventory of existing integration points in the current NAV environment — direct SQL access, .NET interop, file-drop/polling jobs, and any other custom integration surface.
- SaaS-compatibility classification for each integration point — will it work as-is on Business Central SaaS, does it need re-architecture, or is it a dead end that needs replacing entirely.
- Remediation effort estimate per integration point, so the migration project can be scoped and priced with real numbers.
- Recommended sequencing — which integrations to tackle first, and which dependencies block which.
Illustrative report structure
- Executive summary
- Integration inventory
- Risk / SaaS-compatibility classification
- Remediation roadmap
| Integration point | Status | Target pattern | Effort |
|---|---|---|---|
| Direct SQL sales sync | Incompatible with SaaS | AL API page + Azure Function | Medium |
Sample structure shown for illustration only — not drawn from any real client engagement; actual findings are specific to your environment.
View a full sample assessment report (template) — a complete, clearly-labelled example of the deliverable's structure.
Scope
What we work with — and what we don't
The capability range below applies to both offers above. It's meant to make one thing checkable before you reach out: whether your specific environment is in scope.
Capability scope
Codebase range
C/AL in the classic C/SIDE environment through AL extensions on Business Central — including C/AL-to-AL conversion, the core migration skill this practice is built around.
Integration surfaces
BC API pages and OData v4; SOAP web services (legacy surface, typically the starting point for migration); webhook and event-driven patterns; background processing — legacy NAV Application Server (NAS) patterns migrated to Job Queue and Azure-side equivalents.
Azure and identity
Azure Functions, Logic Apps, Service Bus, and Blob Storage; Azure API Management; Entra ID app registrations and OAuth 2.0 client-credentials configuration.
Most AL developers stop at the extension boundary. This practice also covers the adjacent depth that a clean integration re-architecture usually depends on:
Database
SQL Server query and database performance tuning on NAV databases.
Middleware
.NET and Python middleware development.
Documents and reporting
SharePoint and NAV/BC document integration; SQL Server Reporting Services and custom report development.
What we don't do
These are deliberate scope choices, not shortcomings — naming the boundary is part of being a specialist.
- Production support, hypercare, on-call, or incident response of any kind.
- Functional consulting and module configuration — finance, manufacturing, warehouse, and similar. We are developers, not implementation consultants.
- End-user training and documentation.
- Base-application upgrade execution and production data migration — object merges, base-app code conversion, cutover execution, and data conversion. Integration re-architecture performed as part of an upgrade programme is exactly what this practice does; the exclusion is the upgrade project itself, not the integration work a migration requires.
Anything outside this scope is referred back rather than taken on.