During the deployment: onboarding, build and go-live
Provisioning, the timeline from signature to handover, the onboarding form and when each input is due, identity and communications, the migration cockpit, cutover, and the go-live gates.
Provisioning in three steps
| Step | What happens |
|---|---|
| 1 — Proposal & contract | The customer configures cloud, region, nodes, database, DR and environments; audited revenue is provided; the main technical contact is named in the contract. |
| 2 — Build | The onboarding form is submitted; kick-off fixes milestones, responsibilities and the timeline; environments are built from infrastructure-as-code. |
| 3 — Handover | Access goes to the technical contact; the customer verifies connectivity and SSO; configuration and migration begin. |
Build starts only after signature, audited revenue and the onboarding form have all arrived. Start the customer’s network and DNS work in parallel with contracting — it is usually the longest lead item.
Timeline (proposed default, working days)
| From | To | Who | Target |
|---|---|---|---|
| Contract signed | Onboarding form submitted | Customer | 5 working days |
| Onboarding form | Design sign-off | TRANXACT | 5 working days |
| Design sign-off | Committed handover date | TRANXACT | 5 working days, +5 with Live DR (TO_4.1.01) |
Private connectivity, customer-managed keys and extra environments can extend the build. Configuration, migration and testing follow the handover and are planned per module scope.
Commit a go-live date only after the handover date is fixed and the migration plan is sized.
The onboarding form
| Input | Description | When |
|---|---|---|
| Cloud provider & regions | AWS, Azure or Google Cloud; primary and Live DR regions | Before signing |
| Runtime sizing | Worker node size and count (3 minimum); environments | Before signing |
| Database | Engine of choice and size (HA) | Before signing |
| Continuity pattern | Availability tier, Live DR region, vault retention, RPO/RTO | Before signing |
| Modules & scope | Modules at go-live, legal entities, currencies, languages | Before signing |
| Compliance flags | Regulated data (health, education, payroll), retention | Before signing |
| ASK AI | Engine tier or BYOK, processing region, usage budget | Before signing |
| Network | Private /22 ranges (and DR), connectivity option, egress allow-list | Within 5 working days of kick-off |
| DNS & certificates | FQDN, DNS owner, public-CA certificate | Within 5 working days |
| Identity | IdP for SSO, admin users, MFA policy | Within 5 working days |
| Integrations | Bank, payroll, tax, BI and legacy endpoints | Within 5 working days |
| Contacts | Technical, network, security, finance, data migration; two 24×7 contacts | Within 5 working days |
Submitting it is the customer’s task (MIG_8.5.01). Missing inputs delay the committed handover date. Most inputs map straight to the configurator, so reuse the customer’s configuration PDF to pre-fill it.
- Fixed once the build starts: region, address ranges, FQDN, database engine.
- Ranges must not overlap any customer, partner or landing-zone network, including the Live DR region.
- The technical contact should be an IT lead who can act on credentials and network changes — not a CxO, finance or procurement contact (MIG_8.5.03).
- Changes after submission go through the Orchestrator and are logged as non-standard or change requests.
- Track every open input in the fortnightly operations sync until handover.
Identity and communications
- Welcome pack and kick-off invitation after signature (MIG_8.5.02).
- Kick-off (SM_1.1.01): the support manual and service portal, landscape and scope, and a walk through the R&R workbook, RACI and escalation matrix.
- SSO federation with the customer IdP over SAML 2.0 or OIDC (PLAT_5.6.01); SCIM provisioning if wanted (PLAT_5.6.05).
- Role mapping, tested with real users before data migration starts.
- Access reviews scheduled from go-live (PLAT_5.6.04, Excluded).
- All communication goes to the named technical contact; credentials go only to them (TO_4.1.02). A deputy may be named on the form.
- Operational emails — incidents, maintenance, releases — go to the technical contact and the 24×7 contacts.
- Allow-list TRANXACT sender domains so provisioning and alert emails are not quarantined (PLAT_5.5.03).
- A missing email: check spam and quarantine first, then raise a request in the service portal.
- An SSO problem: confirm the IdP metadata, the claim mapping and the test user’s role before raising an incident.
The migration cockpit
- Extract — from legacy systems and spreadsheets (MIG_8.3.01, customer).
- Map — to TRANXACT entities, accounts and master data; cleanse (MIG_8.3.02, customer).
- Validate — rules, duplicates, missing data (MIG_8.2.01, TRANXACT).
- Trial loads — into non-production, repeated (MIG_8.2.01; loads beyond the agreed cycles are Additional, MIG_8.2.02).
- Reconcile — trial balance, sub-ledgers, stock; sign off opening balances (MIG_8.3.03, customer).
- Cutover — freeze, final load and technical verification (MIG_8.4.03, TRANXACT), after the customer’s go / no-go (MIG_8.4.02).
TRANXACT provides the cockpit and load templates (MIG_8.1.01), the migration plan (MIG_8.1.02) and the cutover plan and freeze window, prepared jointly (MIG_8.4.01).
Data quality, not tooling, sets the go-live date. Every opening balance reconciles to the audited source before go-live, and that sign-off is the customer’s.
Checklist: signature to go-live
| Within 5 working days | Build | Handover | Go-live readiness |
|---|---|---|---|
| Onboarding form complete | VPN / private link up | Access verified | Migration reconciled |
| Technical contact named | DNS and certificate live | Monitoring dashboard shared | Integrations tested |
| Egress allow-list drafted | SSO and roles mapped | Vault copies landing | Live DR switchover passed |
| Contacts per area, two 24×7 | Environments built (IaC) | Live DR lag within target | Clean-room restore passed |
After go-live, hypercare — extended support with daily check-ins, typically 4–8 weeks — is available as the H1 package (PKG_7.6.01).
Values marked proposed default are the deployment guide’s recommended starting points. Confirm each one per customer; the contract, order form, SLA and DPA prevail over this page.