Standalone ARM — Migration Plan
1. Executive Summary
This document outlines the strategy, phases, and procedures for migrating the three existing ARM client implementations (Saint Edwards, Al Faisal, Pymble) from their current divergent NetSuite SuiteScript customizations to the unified standalone ARM platform.
Current State
| Client |
Implementation |
Configurator Version |
Key Differences |
| Saint Edwards |
SuiteScript (automated wizard) |
v1 (earliest) |
Yearly billing, flexible payment dates, OTP auth |
| Al Faisal |
SuiteScript (CSV import) |
v2 |
4 fixed terms, fixed payment dates, OTP auth, AED currency |
| Pymble |
SuiteScript (Excel/billing orders) |
v3-4 (most mature) |
Annual billing, 5 payment methods, SSO/JWT, portal integration, building levy, annual discount, Edstart, B Pay |
Migration Principles
- Zero downtime — no interruption to billing or payment processing
- Data integrity — all historical data migrated and verified
- Parallel running — old and new systems run side-by-side during transition
- Rollback capability — ability to revert to NetSuite at any point during migration
- Client communication — parents experience no change (portal, payment links remain valid)
- Phased approach — migrate one client at a time, validate, then proceed
2. Migration Strategy
2.1 Approach: Strangler Fig Pattern
Rather than a big-bang cutover, the standalone ARM gradually takes over functions from the NetSuite implementation:
Phase 1: Standalone ARM reads from NetSuite (shadow mode)
│
Phase 2: Standalone ARM writes to both ARM DB + NetSuite (dual-write)
│
Phase 3: NetSuite reads from ARM (ARM is source of truth)
│
Phase 4: NetSuite customizations decommissioned
2.2 Migration Order
| Order |
Client |
Rationale |
| 1st |
Saint Edwards |
Simplest implementation, smallest data set, good test case |
| 2nd |
Al Faisal |
Moderately complex, introduces multi-currency (AED), CSV import pattern |
| 3rd |
Pymble |
Most complex, largest data set, most integrations, highest risk |
3. Pre-Migration Requirements
Before migrating the first client:
Build a reusable migration tool that:
- Extracts data from NetSuite using SuiteTalk/REST APIs
- Transforms data to match the standalone ARM data model
- Loads data into the ARM database
- Validates record counts, amounts, and relationships
- Generates a migration report with discrepancies
4. Phase-by-Phase Migration
Phase 1: Data Migration (Shadow Mode)
Duration: [PLACEHOLDER: estimated 2-4 weeks per client]
Steps
| Step |
Description |
Validation |
| 1.1 |
Create tenant in ARM |
Verify tenant settings |
| 1.2 |
Export all customer records from NetSuite |
Record count matches |
| 1.3 |
Transform and import as Debtors |
Debtor count = customer count |
| 1.4 |
Export all student data (from SIS or NetSuite child records) |
Record count matches |
| 1.5 |
Transform and import as Students |
Student-to-debtor relationships intact |
| 1.6 |
Export all items (service items + discount items) |
Record count matches |
| 1.7 |
Transform and import as Items |
Item amounts verified |
| 1.8 |
Export billing profiles and instructions |
Record count matches |
| 1.9 |
Transform and import billing structures |
Instruction-to-item-to-student mappings verified |
| 1.10 |
Export all transactions (invoices, billing orders) |
Transaction count and total amounts match |
| 1.11 |
Transform and import as Transactions |
Line items verified |
| 1.12 |
Export all payment records |
Payment count and total amounts match |
| 1.13 |
Transform and import as Payment Records |
Payment-to-transaction linkage verified |
| 1.14 |
Export RPS records |
Active RPS count matches |
| 1.15 |
Transform and import as RPS records + Recurrences |
Payment schedules verified |
| 1.16 |
Run reconciliation report |
All balances match within tolerance |
Data Validation Criteria
| Metric |
Tolerance |
Action if Failed |
| Debtor count |
0% variance |
Block migration |
| Student count |
0% variance |
Block migration |
| Transaction total amounts |
< $0.01 variance per record |
Investigate, log |
| Payment total amounts |
< $0.01 variance per record |
Investigate, log |
| Outstanding balances |
< $0.01 variance per debtor |
Block migration |
| RPS future schedules |
0% variance |
Block migration |
Phase 2: Parallel Running (Dual-Write)
Duration: [PLACEHOLDER: estimated 4-6 weeks per client]
During this phase, both systems process operations:
| Operation |
NetSuite |
ARM |
Source of Truth |
| New debtor creation |
✅ Primary |
✅ Sync |
NetSuite |
| Billing configurator |
✅ Primary |
Observation only |
NetSuite |
| Invoice generation |
✅ Primary |
✅ Shadow generate, compare |
NetSuite |
| Payment processing (eway) |
✅ Primary |
✅ Shadow process, compare |
NetSuite |
| ABA file generation |
✅ Primary |
✅ Shadow generate, compare |
NetSuite |
| Portal access |
✅ Primary |
✅ Shadow (separate URL) |
NetSuite |
| Reporting |
✅ Primary |
✅ Compare reports |
NetSuite |
Shadow Comparison Process
For each operation, ARM independently generates the same output as NetSuite and a comparison report flags discrepancies:
NetSuite generates 150 invoices, total $450,000
ARM generates 150 invoices, total $450,000
Comparison: ✅ Match
NetSuite processes 75 eway payments, total $112,500
ARM processes 75 eway payments (simulated), total $112,500
Comparison: ✅ Match
Exit Criteria for Phase 2
| Criterion |
Target |
| Shadow invoice match rate |
100% |
| Shadow payment match rate |
100% |
| Shadow ABA file match rate (content) |
100% |
| Days of continuous matched operation |
[PLACEHOLDER: minimum 14 days] |
| Zero critical bugs in ARM |
Yes |
| Client stakeholder sign-off |
Yes |
Phase 3: Cutover (ARM as Primary)
Duration: Cutover window — 1 weekend
Cutover Checklist
| Step |
Timing |
Action |
Rollback |
| 3.1 |
Friday 6pm |
Freeze NetSuite billing operations |
— |
| 3.2 |
Friday 7pm |
Final data sync: NetSuite → ARM |
— |
| 3.3 |
Friday 8pm |
Validate final sync (run reconciliation) |
Abort if failed |
| 3.4 |
Friday 9pm |
Switch DNS for payment portal to ARM |
Switch back to NS |
| 3.5 |
Saturday 9am |
Test portal access (internal team) |
— |
| 3.6 |
Saturday 10am |
Test payment processing (eway sandbox) |
— |
| 3.7 |
Saturday 12pm |
Configure NetSuite adapter for read-only sync |
— |
| 3.8 |
Sunday |
Monitor all systems |
— |
| 3.9 |
Monday 9am |
Enable ARM billing operations |
— |
| 3.10 |
Monday |
Monitor first business day |
Full rollback available |
Post-Cutover Operations
| Operation |
Now handled by |
NetSuite role |
| Billing configurator |
ARM |
Receives sync for GL |
| Invoice generation |
ARM |
Receives created invoices for accounting |
| Payment processing |
ARM |
Receives payment records |
| Parent portal |
ARM |
Decommissioned (NS portal) |
| Reporting |
ARM |
NetSuite still has financial reporting |
| RPS scheduling |
ARM |
Decommissioned (NS scheduled scripts) |
Phase 4: Decommission NetSuite Customizations
Duration: [PLACEHOLDER: 4-8 weeks after cutover]
Timing: Only after ARM has run successfully as primary for a minimum stabilization period.
| Step |
Action |
| 4.1 |
Disable NetSuite scheduled scripts (billing, RPS) |
| 4.2 |
Remove NetSuite Suitelets (configurator, portal) |
| 4.3 |
Archive NetSuite custom records (keep read-only) |
| 4.4 |
Remove NetSuite client scripts and user event scripts |
| 4.5 |
Update NetSuite roles/permissions |
| 4.6 |
Document decommissioned components |
| 4.7 |
Final sign-off from client |
5. Client-Specific Migration Notes
5.1 Saint Edwards
| Aspect |
Current State |
Migration Notes |
| Billing |
Yearly, automated wizard |
Replicate wizard as ARM template |
| Payment dates |
Flexible (parent-chosen) |
Configure flexible_dates = true |
| Payment methods |
Credit card (eway), direct debit (ABA) |
Standard integrations |
| Authentication |
OTP |
Standard portal OTP |
| Currency |
AUD |
Standard |
| Special features |
None identified |
Simplest migration |
| Data volume |
[PLACEHOLDER] debtors, [PLACEHOLDER] students |
— |
5.2 Al Faisal
| Aspect |
Current State |
Migration Notes |
| Billing |
4 fixed terms, CSV import |
Configure 4-term cycle, build CSV import template |
| Payment dates |
Fixed per term |
Configure flexible_dates = false, set fixed_payment_dates |
| Payment methods |
Credit card (eway), direct debit (ABA) |
Standard integrations |
| Authentication |
OTP |
Standard portal OTP |
| Currency |
AED |
Configure tenant currency = AED |
| Special features |
Arabic language support |
[PLACEHOLDER: i18n requirements] |
| Data volume |
[PLACEHOLDER] debtors, [PLACEHOLDER] students |
— |
| Known issues |
None documented |
— |
5.3 Pymble
| Aspect |
Current State |
Migration Notes |
| Billing |
Annual, Excel import, billing orders |
Most complex; needs billing order workflow |
| Payment dates |
Flexible (parent-chosen) |
Configure flexible_dates = true |
| Payment methods |
Credit card, direct debit, B Pay, Edstart, annual upfront |
All 5 methods must be configured |
| Authentication |
SSO via JWT (My Pymble) |
Configure JWT validation with Pymble's key |
| Currency |
AUD |
Standard |
| Special features |
Building levy (opt-in), 2.5% annual discount, sibling discounts, mid-year enrollment, billing orders → invoices flow, "Paid from Portal" flag, opening balance calculation |
Each feature must be explicitly tested post-migration |
| Data volume |
[PLACEHOLDER] debtors, [PLACEHOLDER] students |
Largest client |
| Known issues |
Multiple documented issues (see clients/pymble/support/known-issues.md) |
Must verify all known issues resolved OR documented as out-of-scope |
6. Rollback Procedures
6.1 Pre-Cutover Rollback (Phase 1-2)
- Action: Simply stop ARM operations; NetSuite continues as-is
- Data: No ARM data loss concerns (NetSuite was primary)
- Impact: Zero customer impact
6.2 Post-Cutover Rollback (Phase 3-4)
| Step |
Action |
Duration |
| 1 |
Freeze ARM operations |
Immediate |
| 2 |
Sync any ARM-only data back to NetSuite |
[PLACEHOLDER: estimated 2-4 hours] |
| 3 |
Switch DNS for portal back to NetSuite |
5 min (DNS propagation) |
| 4 |
Re-enable NetSuite scheduled scripts |
15 min |
| 5 |
Validate NetSuite operations |
1 hour |
| 6 |
Communicate to stakeholders |
— |
Maximum rollback window: [PLACEHOLDER: define based on data sync feasibility, likely 2-4 weeks post-cutover]
7. Risk Register
| Risk |
Likelihood |
Impact |
Mitigation |
| Data mismatch during migration |
Medium |
High |
Automated reconciliation + manual spot checks |
| Payment processing failure post-cutover |
Low |
Critical |
Parallel running period validates; eway sandbox testing |
| Parent portal downtime during cutover |
Low |
Medium |
Weekend cutover; DNS pre-propagation |
| NetSuite API rate limits during extraction |
Medium |
Low |
Batch extraction during off-hours; queue-based |
| Pymble SSO/JWT integration breaks |
Low |
High |
Pre-cutover testing with Pymble IT team |
| Historical data volume exceeds estimates |
Low |
Medium |
Performance testing with realistic data |
| Staff training gaps |
Medium |
Medium |
Training sessions + documentation before cutover |
| Client resists change |
Low |
Medium |
Transparent communication; demonstrate parallel results |
8. Timeline
[PLACEHOLDER: Detailed timeline — depends on team capacity and client availability]
Estimated high-level timeline:
Month 1-3: Platform build (core ARM + NetSuite adapter)
Month 4: Saint Edwards — Phase 1 (data migration)
Month 5: Saint Edwards — Phase 2 (parallel running)
Month 6: Saint Edwards — Phase 3 (cutover) + Phase 4 (decommission)
Month 7: Al Faisal — Phase 1
Month 8: Al Faisal — Phase 2
Month 9: Al Faisal — Phase 3 + 4
Month 10: Pymble — Phase 1
Month 11-12: Pymble — Phase 2
Month 13: Pymble — Phase 3 + 4
9. Success Criteria
| Metric |
Target |
| Data migration accuracy |
100% (zero record loss) |
| Financial reconciliation |
$0.00 variance |
| Payment processing uptime |
99.9% |
| Parent portal uptime post-cutover |
99.9% |
| Mean time to resolve (post-cutover issues) |
< 4 hours |
| Client satisfaction score |
[PLACEHOLDER] |
| All known issues resolved or documented |
Yes |
| NetSuite customization fully decommissioned |
Yes (per client timeline) |