SYSPRO to Dynamics 365 Business Central Migration Guide

SYSPRO to Dynamics 365 Business Central Migration Guide

Migrating from SYSPRO to Microsoft Dynamics 365 Business Central is a structural data translation problem — meaning the challenge is not copying records but decomposing SYSPRO's module-prefixed, SQL-native schema into Business Central's posting-group-driven, dimension-annotated entity model. Microsoft's built-in cloud migration tooling does not include a SYSPRO-specific path — SYSPRO falls under the custom SQL-based migration route alongside any other non-Microsoft ERP, much like SAP Business One. (learn.microsoft.com)

You are moving from a manufacturing-first, on-premise ERP with a segmented SQL Server database into a cloud-native SaaS platform driven by posting groups, dimensional accounting, and AL extensions. If you push SYSPRO tables directly into Business Central without redesigning posting groups, rebuilding BOM structures, and reconciling GL integration codes, the migration will fail on import — or worse, on the first user transaction after go-live.

The real work is extraction from SQL Server, field-level mapping across 25–50 active SYSPRO tables, handling the manufacturing data gap between SYSPRO's deep shop-floor model and BC's Premium-tier production module, and managing Business Central's API rate limits during load. This guide covers the architectural mismatches, SYSPRO's 2026 licensing shift, object-by-object data mapping, extraction methods, loading strategies, delta sync mechanics, API authentication, and how to execute without disrupting production.

For related migration patterns, see Manufacturing ERP Migration: Move to Dynamics 365 With Zero Downtime and What Data Should You Actually Migrate to Your New ERP?.

Why Manufacturers Are Leaving SYSPRO in 2026

Three forces are pushing SYSPRO customers toward Business Central right now.

The subscription licensing shift. SYSPRO is discontinuing its perpetual Initial License Fee and Annual License Fee model, requiring all customers to move to a named-user, subscription-based platform. For U.S. customers, existing perpetual licenses remain valid through December 31, 2026. Outside the U.S., the cutoff is October 31, 2026. Customers who were budgeting around a perpetual on-premises cost structure now face a forced reassessment — a dynamic also driving NetSuite to Business Central migrations — and many are concluding that if they're paying subscription pricing anyway, they'd rather pay it for a cloud-native platform with broader ecosystem integration.

Integration friction. SYSPRO's integration surface is fragmented. The OData REST service is read-only and capped at 5,000 rows per request. Write operations exist only through the SOAP-based e.net business objects layer. Connecting SYSPRO to modern SaaS tools — CRM, ecommerce, BI — typically requires custom middleware. Business Central, by contrast, exposes ~55 standard API v2.0 endpoints with full CRUD over OData v4, native Power Platform connectors, and Teams/Outlook integration out of the box.

Manufacturing module parity. Business Central Premium ($110/user/month as of 2026) now includes production orders, multi-level production BOMs, routings, work and machine centers, MRP, MPS, and capacity planning. For the mid-market discrete manufacturers that make up SYSPRO's core base — typically 20–500 users running make-to-stock or make-to-order — BC Premium covers the production planning essentials. The gap that remains is real and matters for some buyers. The table below compares specific capabilities:

For companies not actively using finite scheduling, co-product handling, or the native SYSPRO shop floor module, the BC Premium gap is narrower than it was in 2022. For those that rely on SYSPRO's finite scheduling engine, that feature has no native BC equivalent and requires a third-party ISV add-on.

How Is SYSPRO's Database Structured?

SYSPRO 8 stores all data in Microsoft SQL Server, using a system-wide database plus a separate company-specific database for each SYSPRO company. Each company database contains approximately 1,000 tables, though only about 25–50 see heavy transactional activity. Tables use a module-prefix naming convention:

Custom form data lives in separate "plus" tables — ArCustomer+, InvMaster+, etc. — which have dynamic, user-defined schemas. These tables are not part of the standard data dictionary, so any migration script must discover their structure at runtime using INFORMATION_SCHEMA.COLUMNS against the company database, filtered by the + suffix convention. SYSPRO also exposes custom form tables through OData with a _company suffix, but custom forms that don't follow standard naming conventions are excluded from the OData feed. (help.syspro.com)

SYSPRO columns use CamelCase naming with a maximum of 18 characters and are mostly defined as NOT NULL. Every table includes a TimeStamp column used for SQL Server concurrency control — this column is also the basis for delta sync (see Delta Sync Mechanics below).

SYSPRO to Business Central: Object-by-Object Data Mapping

The mapping challenge is not volume — it's structural. SYSPRO's module-prefix tables must translate into Business Central's posting-group-driven entity model. Here is where each object type breaks.

Chart of Accounts and GL

SYSPRO's GenMaster holds GL account codes, often using a segmented structure where a single account string encodes the natural account, department, division, and other analytical segments. Business Central uses a flat Chart of Accounts (natural account only) with Dimensions applied as analytical tags at the transaction level.

Worked example — GL segment decomposition:

A SYSPRO GL account string like 1100-040-US-EAST might encode:

• 1100 = Natural account (Cash — Operating)
• 040 = Department (Manufacturing)
• US = Region
• EAST = Territory

In Business Central, this decomposes as:

• BC Account No.: 1100 (Chart of Accounts)
• Global Dimension 1: 040 (mapped to a "Department" dimension)
• Global Dimension 2: US-EAST (mapped to a "Region" dimension, combined or split depending on your cardinality)

If you have more than two analytical segments, the additional segments become Shortcut Dimensions 3–8 on the dimension setup page. The total BC limit is 2 global + 6 shortcut = 8 dimensions.

Business Central supports two global dimensions and eight shortcut dimensions total. Microsoft warns that changing global dimensions after initial setup can be time-consuming, affect performance, and lock tables during the update process. (learn.microsoft.com) Design your dimension structure before loading any data — this decision cannot be easily reversed.

On top of the Chart of Accounts, BC requires Posting Groups — General Business, General Product, Customer, Vendor, and Inventory posting groups — that control how every transaction hits the ledger. There is no 1:1 SYSPRO equivalent. You must design the BC posting group matrix before importing a single customer or item record, because BC rejects any entity that references an undefined posting group. (learn.microsoft.com)

Historical GL transactions are typically loaded as opening balance journal entries rather than migrated line-by-line. Migrating full transaction history into BC's G/L Entry table is possible but rarely worth it — see the historical data section below.

Customers and Vendors

ArCustomer maps to BC's Customer table (Table 18). ApSupplier maps to Vendor (Table 23). Field-level mapping is straightforward for name, address, and contact fields, but watch for:

• Customer/Vendor posting groups: mandatory in BC, nonexistent as a concept in SYSPRO. Assign these during transformation.
• Payment terms and currency codes: SYSPRO stores these as free-form or lookup values that may not match BC's predefined code tables. Clean them before import.
• Custom form fields (ArCustomer+, ApSupplier+): these have no fixed schema. Map them to BC custom fields or AL table extensions defined before import.

Inventory and Items

InvMaster maps to BC's Item table (Table 27). This is where complexity spikes for manufacturers.

Costing methods: SYSPRO supports Standard, Average, FIFO, LIFO, and Last Cost. Business Central supports FIFO, LIFO, Average, Standard, and Specific. The mapping is close but not identical — validate that your costing method transfers correctly, especially if you use SYSPRO's weighted average with manual adjustments. The Costing Method field on the BC Item Card must be set correctly on initial import. Once an item has posted ledger entries in BC, changing the costing method requires deleting all item ledger entries and value entries for that item, or using a workaround that involves creating a new item number. This is not a minor adjustment — it requires a full re-migration of that item.

Every Item in BC also requires an Inventory Posting Group and a Gen. Prod. Posting Group. These drive the GL accounts hit during inventory movements and must be assigned before import.

Units of measure: SYSPRO's UOM handling per stock code must map to BC's Item Unit of Measure table, which supports multiple UOMs per item with conversion factors.

Lot and serial tracking: SYSPRO tracks lots and serials at the inventory level. BC uses Item Tracking Codes assigned to items, with separate lot and serial number tracking configurations. Set up tracking codes before importing item records. For manufacturers in regulated industries, failing to map lot tracking correctly means losing traceability — an audit failure, not just a data gap.

Warehouse data (InvWarehouse): maps to BC's Location (Table 14) and Item Journal for opening stock quantities. If your SYSPRO site uses warehouse discipline, BC's directed put-away and pick model — with bins, bin ranking, and blocked/dedicated stock rules — needs to be planned explicitly. Don't just load a single balance per item. (learn.microsoft.com)

Business Central enforces strict character limits — 20 characters for No. fields, for example. If your SYSPRO StockCode exceeds 20 characters, implement a truncation or mapping strategy during extraction.

-- Example: Extracting active inventory items with costing from SYSPRO
SELECT 
    StockCode,
    Description,
    LongDesc,
    StockUom,
    CostingMethod,
    MaterialCost,
    ProductClass
FROM InvMaster
WHERE StockOnHold = 'N'

Bills of Materials and Routings

This is the most migration-sensitive area. SYSPRO's BomStructure maps to BC's Production BOM (Table 99000771), and BomOperations maps to BC Routings (Table 99000763). Both require the Premium license.

Production BOM vs. Assembly BOM — decision rule:

If you flatten SYSPRO jobs, WIP structures, and routings into assembly data because it imports faster, you lose work-center, machine-center, routing-link, and cost-roll behavior the business actually uses. The choice of BOM type cannot be changed after production orders have been created against an item. (learn.microsoft.com)

BOM status lifecycle: SYSPRO BOMs must be inserted into BC with status New, lines populated, then status updated to Certified via a separate API call. Only Certified Production BOMs can be assigned to production orders. If you import BOMs without completing the certification step, your production team cannot plan against them on day one.

SYSPRO supports multi-level BOMs with phantom assemblies, sub-assemblies, effectivity dates, and revision control. BC Production BOMs support multi-level structures with phantom BOMs, version management, and status control (New, Certified, Under Development, Closed). Effectivity dates in SYSPRO have no direct BC equivalent — if you use date-controlled BOM revisions in SYSPRO, you must implement them as BC BOM versions with explicit start dates.

Routing operations in SYSPRO reference work centers with run times, setup times, and labor/machine rates. These map to BC's Work Centers and Machine Centers, but the rate and capacity structures differ. Plan to rebuild routing master data rather than attempting a field-level copy — the rate calculation models are sufficiently different that a direct copy typically produces incorrect standard costs.

Open production orders (WipMater): migrating in-flight WIP is high-risk. The standard practice is to complete or close all open production orders in SYSPRO before cutover, then create new production orders in BC post-migration.

Sales and Purchase Orders

Open SorMaster/SorDetail records map to BC Sales Orders (Tables 36/37). Open PorMasterHdr/PorMasterDetail map to BC Purchase Orders (Tables 38/39).

Only migrate open orders. Completed and shipped orders belong in the archive, not in the live BC environment.

Business Central requires that Sell-to Customer No., Bill-to Customer No., and Location Code are perfectly aligned with master data already loaded in BC. Line-level fields like tax codes, discount structures, and delivery schedules need transformation to match BC's setup tables.

Open orders import in an "Open" status. You must decide whether to programmatically "Release" these orders via the API after import, which triggers BC's internal validation and reservation logic.

How Do You Extract Data from SYSPRO?

Three extraction paths exist, in order of preference.

1. Direct SQL Server access. Because SYSPRO stores everything in SQL Server, direct database queries are the fastest and most reliable extraction method. You get full access to all ~1,000 tables per company database, custom form "plus" tables, and can write complex joins that the API layer doesn't support.

SYSPRO's Business Activity Queries (BAQs) are also useful for extraction. SYSPRO defines BAQs as SQL views in the company database, and once published they're accessible through both direct SQL and the OData feed. BAQs are a good fit when you need denormalized or governed datasets — customer masters, open-order snapshots, inventory balances, or pre-joined manufacturing data that would be awkward to assemble record-by-record. (help.syspro.com)

2. SYSPRO OData (read-only). SYSPRO's OData service provides RESTful read access across all modules with filtering, sorting, and pagination. Responses are capped at 5,000 rows per request and the service is read-only — no write-back validation. For large datasets, it's too slow for bulk extraction.

3. SYSPRO e.net business objects (SOAP). The e.net layer supports full CRUD operations but uses XML-based SOAP calls through a WCF service. It's designed for transactional integration, not bulk extraction. Useful when SYSPRO business logic matters more than raw throughput — validating difficult objects, for example — but not practical for initial migration loads. (help.syspro.com)

For most migrations, direct SQL extraction is the only method that gives you the speed and coverage to handle the full object set. When extracting, cast and format dates, decimals, and string lengths to match Business Central's schema requirements.

How Do You Load Data into Business Central?

API Authentication Setup

Business Central Online uses OAuth 2.0 client credentials flow for server-to-server migration loads. Do not use delegated (user) credentials — they are subject to interactive session timeouts and per-user rate limits that will interrupt a bulk load.

Required setup steps:

1. Register an app in Azure Active Directory (now Entra ID) for your BC tenant. Grant it Dynamics 365 Business Central → API application permissions, not delegated permissions.
2. Create a service principal in BC: in the Business Central admin center, under Azure Active Directory Applications, register the app's client ID and grant it the D365 Full Access or a custom permission set covering the entities you need to write.
3. Acquire a token using the client credentials flow:

   POST https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token
   Body: grant_type=client_credentials
         client_id={app_id}
         client_secret={secret}
         scope=https://api.businesscentral.dynamics.com/.default
   

4. Use the token in all API calls as a Bearer token in the Authorization header.
5. Per-environment endpoint pattern:

   https://api.businesscentral.dynamics.com/v2.0/{tenant_id}/{environment_name}/api/v2.0/companies({company_id})/{entity}
   

To multiply throughput, register multiple service principals and distribute entity loads across them — each principal has its own rate limit bucket.

Loading Strategy and Rate Limits

Business Central API v2.0 is the preferred import path. It exposes OData v4 endpoints with full CRUD for ~55 standard entities including customers, vendors, items, sales orders, purchase orders, and GL journal entries. (learn.microsoft.com)

The rate limits that govern throughput:

Your migration tooling must handle 429 Too Many Requests, 503, and 504 responses with retries, backoff periods, and smaller batch splits when a request runs too long. This is not optional engineering polish — it's the minimum shape of a loader that can survive BC Online at scale. (learn.microsoft.com)

Common BC API rejection errors by entity type:

For large loads: use $batch requests to group writes (up to 100 per batch), spread load across multiple service principal accounts to multiply your per-user quota, and stage imports by entity type — posting groups and setup tables first, then master data, then open documents, then opening balances.

Configuration Packages (formerly RapidStart Services) handle master data and setup data via Excel-based templates. They work for chart of accounts, payment terms, posting groups, and smaller master data sets. Performance degrades significantly for large record sets, and importing locks users out of the company during processing. Microsoft states that configuration packages are not intended for companies already in production. (learn.microsoft.com) Use them for setup data; use the API for transactional volume.

Do not build new migration plumbing on SOAP. Microsoft states that API or OData executes faster, and that SOAP throughput will be reduced and the protocol deprecated in the future. When standard BC APIs don't expose the structure you need, the supported route is to create table/page extensions or custom API pages in AL.

ISV Dependencies That Affect the Data Model

If your BC implementation includes common ISVs, these affect data model decisions before migration begins:

• Continia Document Capture / Expense Management: adds its own vendor and purchase document tables; coordinate import order with the ISV's setup requirements.
• Jet Reports / Jet Analytics: requires a clean dimension structure at go-live; importing malformed dimension values will corrupt Jet's data warehouse sync.
• Vicinity Manufacturing (if replacing SYSPRO shop floor with a BC ISV): Vicinity uses custom production order extensions — load their base configuration before importing production BOMs.
• AutoSimply / Prodsmart: similar ISV-first setup requirement before production data import.

Confirm with your BC implementation partner which ISVs are in scope and whether any add tables that must exist before master data is loaded.

What Data Should You Actually Migrate?

One of the most common mistakes when leaving SYSPRO — similar to what we see in QuickBooks to Business Central migrations — is attempting to migrate every historical journal entry line-by-line into Business Central.

Business Central's database size is metered, and Microsoft charges for storage overages. Loading 15 years of daily SYSPRO GL transactions into BC will bloat your cloud storage costs and degrade system performance. BC Online also caps query execution at 30 minutes and 1,000,000 rows, which means bulk history loads and post-load validations must be chunked deliberately. (learn.microsoft.com)

The standard practice is to migrate:

1. Master Data — All active customers, vendors, and items.
2. Open Transactions — Unpaid AR, unpaid AP, open sales orders, open purchase orders.
3. Opening Balances — A trial balance journal entry for the current fiscal year, cut over on the last day of the month.
4. Historical Summary — Monthly net change balances for the past 2–3 years to support comparative reporting.
5. Active Manufacturing Data — Current BOMs (Certified status), routings, active price lists.

Detailed historical transactions — a specific sales invoice from 2018, for instance — should be extracted from SYSPRO and archived in a data lake (Azure Data Lake, AWS S3) and queried via Power BI when necessary. Everything else should earn its place in the live system.

For deeper guidance on scoping, see What Data Should You Actually Migrate to Your New ERP?.

Cutover Timing Strategy

"Run over a weekend" is incomplete guidance. A SYSPRO-to-BC cutover requires alignment on five timing decisions:

1. Fiscal month-end alignment. Cut over on the last working day of a fiscal month. This minimizes the number of partial-month transactions in SYSPRO that must be reconciled against the opening balance in BC. Never cut over mid-month if avoidable.

2. AR/AP aging cutoff. Pull the SYSPRO AR aging report as of cutover date. Every open invoice in that report must appear in BC's open Customer Ledger Entries. Reconcile total open AR in BC against the SYSPRO aging total before go-live sign-off. Repeat for AP.

3. Inventory valuation date. The opening inventory journal in BC must use the same valuation date as the last SYSPRO inventory close. For Standard cost items, confirm that SYSPRO's standard costs are replicated exactly on the BC Item Card before posting the opening balance journal — a cost discrepancy at this step creates a permanent variance.

4. In-flight transactions. Transactions posted in SYSPRO after the bulk extraction but before go-live must be captured in the delta sync window. Define a hard freeze time — typically midnight on the Friday before a Monday go-live — after which no new SYSPRO transactions are posted. Any transactions between the bulk extract and the freeze must be identified (using the TimeStamp column) and loaded as delta records.

5. Open production order closure. All WIP production orders must be closed or completed in SYSPRO before cutover. New production orders are created from scratch in BC post-go-live using the migrated BOMs and routings.

Delta Sync and Cutover Mechanics

Step 6 of the execution sequence ("delta sync") requires a concrete mechanism. Here is how it works in practice.

The mechanism: SQL Server TimeStamp column comparison.

Every SYSPRO table contains a TimeStamp column (SQL Server rowversion type) that updates automatically whenever a row is modified. This is the basis for change detection without requiring SQL Server Change Data Capture (CDC), which may not be enabled on SYSPRO production databases.

Delta sync process:

1. At the end of the bulk migration, record the maximum TimeStamp value observed across each extracted table. Store this as the "watermark."
2. During the delta sync window (between bulk load completion and cutover), query each SYSPRO table for rows where TimeStamp > watermark:

   SELECT * FROM ArCustomer
   WHERE [TimeStamp] > @last_watermark

3. Transform and load changed records using the same transformation rules as the bulk load. For records that already exist in BC, use PATCH (update); for new records, use POST (insert).
4. Repeat the watermark capture after each delta cycle.
5. At cutover freeze time, run one final delta pass, validate record counts, and cut over.

Limitations of TimeStamp-based delta sync:

• Detects updates and inserts but not hard deletes. If a SYSPRO record is deleted between bulk load and cutover, the delta sync will not remove it from BC. Handle deletes via a separate reconciliation query: compare primary key sets between SYSPRO and BC for each entity type.
• TimeStamp is not a wall-clock time — it is a monotonically increasing database-wide counter. You cannot use it to filter by calendar date; you must store the actual TimeStamp binary value as the watermark.

For environments where SQL Server CDC is enabled, CDC change tables provide a more complete audit trail including deletes and the before/after values of changed columns — but CDC setup requires DBA access to the SYSPRO production server and is not always available.

What Breaks If You Get the Migration Wrong

The failure modes below are not theoretical — they represent the most common rejection and post-go-live errors in SYSPRO-to-BC migrations, ordered by frequency of occurrence.

1. Posting group mismatches (most common). Every customer, vendor, and item in BC requires valid posting groups. Import a customer record without one and BC rejects it at import. Import it with the wrong one and every invoice posts to the wrong GL account — silently. The error may not surface until month-end close. Map posting groups first, test with a sample migration, and validate GL posting behavior against a known SYSPRO transaction before the full load.

2. BOM status conflicts. BC Production BOMs have a status lifecycle (New → Certified). Only Certified BOMs can be used on production orders. If you import BOMs without completing the certification API call, your production team can't plan against them on day one. The certification step is a separate API PATCH call to set status = "Certified" after all BOM lines are loaded.

3. Costing method lock-in. Once an item has posted ledger entries in BC, its costing method cannot be changed without deleting all item ledger entries. If you import items with the wrong costing method and your team posts even one transaction, correction requires a full item re-migration.

4. Custom form data loss. SYSPRO's "plus" tables contain user-defined fields with dynamic schemas. BC has no direct equivalent — you need AL table extensions defined before import. Skip this step and you lose all custom field data permanently.

5. Lot and serial traceability gaps. If SYSPRO lot tracking data doesn't map correctly to BC's Item Tracking system, you lose traceability on regulated products. For manufacturers in regulated industries, this is an audit failure, not a data quality issue.

6. Dimension design mistakes. If you import years of inconsistent SYSPRO branch, territory, or product-line coding into BC dimensions without normalization, you inherit the mess in a system where changing global dimensions later locks tables and degrades performance. Dimension normalization must happen during the transformation phase, not post-migration.

7. Effectivity date loss. SYSPRO BOM effectivity dates have no direct BC equivalent. If you migrate BOMs without converting effectivity dates to BC version start dates, date-controlled BOM revisions are silently lost.

How Long Does a SYSPRO to Business Central Data Migration Take?

The data migration itself — extraction, transformation, loading, and validation — typically completes within 1–5 business days, depending on data volume, complexity, and API rate limits. Small datasets under 10,000 records can finish in under 24 hours. Full migrations typically run over a weekend.

By volume:

• 1–500 documents: 1–2 days
• 500–5,000 documents: 3–7 days
• 5,000+ documents: custom engagement, usually an initial bulk migration followed by delta syncs

The Migration Execution Sequence

1. Connect and extract — Establish secure read-only SQL access to SYSPRO's database. Full schema discovery including "plus" tables via INFORMATION_SCHEMA.COLUMNS. Record the maximum TimeStamp watermark for each table at extraction time.
2. Design the BC posting group matrix — Map SYSPRO GL integration codes to Business Central's General Business, General Product, Customer, Vendor, Inventory, and Manufacturing posting groups. These must exist in BC before any entity import.
3. Design dimension structure — Decompose SYSPRO GL segment strings into BC account numbers plus Global Dimension 1, Global Dimension 2, and Shortcut Dimensions 3–8 as needed. Normalize inconsistent historical coding before import. This decision cannot be easily changed post-migration.
4. Set up BC API authentication — Register an Azure AD / Entra ID app, create BC service principal(s), configure API permissions, and validate OAuth 2.0 client credentials token acquisition before any load begins.
5. Build the transformation layer — Field-level mapping scripts handling data type conversions, code lookups, UOM normalization, posting group assignment, BOM effectivity-to-version conversion, and custom field translation from SYSPRO's "plus" tables to BC AL extensions.
6. Run sample migrations — Load a representative subset into a BC sandbox. Validate record counts, field values, GL posting behavior, BOM certification status, and item tracking. Run until the data is right before proceeding to full load.
7. Execute the full migration — Bulk load via BC API v2.0 with $batch operations, staged by entity type in dependency order: setup tables and posting groups first, then master data (customers, vendors, items), then BOMs and routings (with certification step), then open documents (orders), then opening balance journals. Validate with checksums, record-count parity, and referential integrity checks.
8. Delta sync and cutover — Run TimeStamp-based delta queries against each SYSPRO table to capture changes since the bulk extraction watermark. Load changed records via PATCH/POST. Run a delete reconciliation pass to identify hard-deleted SYSPRO records. At the cutover freeze time, execute a final delta pass, validate AR/AP aging totals, inventory valuation, and open order counts against SYSPRO, then switch users.

For manufacturing migrations, close all open production orders in SYSPRO before cutover. Migrating in-flight WIP between two different production order engines introduces too much risk for too little value.

What This Costs

Business Central licensing: Premium at $110/user/month if you need manufacturing features. Essentials at $80/user/month for distribution-only operations covering financials, sales, purchasing, and inventory.

Migration pricing depends on data volume, number of entity types, BOM depth, custom field complexity, and whether delta sync is required. A free scoping call produces a fixed-price proposal — no hourly billing, no per-record metering.