Claude-code-plugins-plus navan-migration-deep-dive
git clone https://github.com/jeremylongshore/claude-code-plugins-plus-skills
T=$(mktemp -d) && git clone --depth=1 https://github.com/jeremylongshore/claude-code-plugins-plus-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/plugins/saas-packs/navan-pack/skills/navan-migration-deep-dive" ~/.claude/skills/jeremylongshore-claude-code-plugins-plus-navan-migration-deep-dive && rm -rf "$T"
plugins/saas-packs/navan-pack/skills/navan-migration-deep-dive/SKILL.mdNavan Migration Deep Dive
Overview
End-to-end migration playbook for moving from SAP Concur or legacy travel management systems to Navan. Navan uses REST APIs with OAuth 2.0 — there is no SDK, no automated migration tool, and no sandbox for testing.
Prerequisites
- Admin access to both source system (SAP Concur, legacy TMC) and Navan
- Navan OAuth credentials from Admin > Travel admin > Settings > Integrations
- Data export from source system (expense reports, itineraries, user directory)
- SSO identity provider (Okta, Azure AD, Google Workspace) for user provisioning
- Executive sponsor and travel program manager identified
Instructions
Phase 1 — Discovery and Planning (Weeks 1-2)
Inventory current state:
| Data Category | SAP Concur Source | Navan Target | Migration Method |
|---|---|---|---|
| User profiles | Concur user export (CSV) | SCIM provisioning or API | IdP-driven |
| Travel policies | Concur policy rules | Navan admin console | Manual recreation |
| Expense categories | Concur expense types | Navan expense categories | Mapping table |
| Historical bookings | Concur trip export | Archive only (not imported) | Export + cold storage |
| Historical expenses | Concur expense reports | Archive only (not imported) | Export + cold storage |
| Approval workflows | Concur approval chains | Navan approval policies | Manual recreation |
| Corporate card feeds | Concur card integrations | Navan card program or integration | New setup |
Key decision: historical data strategy. Navan does not support importing historical booking or expense data. Export source system data to a data warehouse or archive storage for reference. Future Navan data starts fresh from migration day.
Phase 2 — User Provisioning (Weeks 2-3)
Option A — SCIM provisioning (recommended):
- Configure SCIM connector in your IdP (Okta, Azure AD)
- Map IdP groups to Navan roles: traveler, travel arranger, approver, admin
- Enable provisioning — users are created in Navan automatically
- Test with a pilot group (10-20 users) before full rollout
Option B — CSV bulk upload:
- Export user directory from source system
- Format per Navan's CSV template (available in Admin > User Management)
- Upload via Navan admin console
- Manually verify role assignments
Verify provisioned users via API:
TOKEN=$(curl -s -X POST "https://api.navan.com/ta-auth/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials&client_id=$NAVAN_CLIENT_ID&client_secret=$NAVAN_CLIENT_SECRET" \ | jq -r '.access_token') # Count provisioned users curl -s -H "Authorization: Bearer $TOKEN" \ "https://api.navan.com/v1/users" \ | jq '{total: (.data | length), sample: [.data[:3][] | {email, status}]}'
Phase 3 — Policy Recreation (Weeks 3-4)
Recreate travel policies in Navan admin console. Key policy areas:
- Booking policies: Flight class limits (economy/business by route length), hotel rate caps by city, advance booking requirements
- Approval workflows: Auto-approve under threshold, manager approval above, VP approval for international
- Expense policies: Per diem rates, receipt requirements, out-of-policy flagging
- Preferred vendors: Airline/hotel preferences, negotiated corporate rates, loyalty program linkage
- Traveler profiles: Default seat preferences, meal requirements, loyalty numbers, passport info
SAP Concur policy mapping pitfalls:
- Concur's "travel rules" do not map 1:1 to Navan's policy engine — expect manual translation
- Concur custom fields require mapping to Navan's cost center / department / project structure
- Concur delegation rules differ from Navan's travel arranger model
Phase 4 — Parallel Running (Weeks 4-6)
Run both systems simultaneously to validate the migration:
| Activity | Source System | Navan | Duration |
|---|---|---|---|
| New bookings | Disabled for pilot group | Active for pilot group | 2 weeks |
| Expense submission | Active (all users) | Active (pilot group) | 2 weeks |
| Approval workflows | Active | Tested with pilot | 2 weeks |
| Reporting | Primary | Validated against source | 2 weeks |
# Monitor booking volume in Navan during parallel run curl -s -H "Authorization: Bearer $TOKEN" \ "https://api.navan.com/v1/bookings?page=0&size=50&createdFrom=$(date -d '7 days ago' +%Y-%m-%d)" \ | jq '{total_bookings: (.data | length)}'
Reconciliation checks:
- Compare booking counts between systems weekly
- Validate expense report totals match between systems
- Verify approval chains produce consistent outcomes
- Test edge cases: international travel, group bookings, last-minute changes
Phase 5 — Cutover (Week 6-7)
Go/no-go checklist (all must pass):
- All users provisioned and can log in via SSO
- Travel policies match source system intent (reviewed by travel manager)
- Pilot group has booked 20+ trips without issues
- Expense submission and approval tested end-to-end
- Corporate card feeds connected (if applicable)
- Navan API integration healthy (auth + data endpoints return 200)
- Fivetran/Airbyte data sync running for BOOKING and TRANSACTION tables
- Rollback procedure documented and tested
- User training materials distributed
- IT support team briefed on Navan admin and Ava AI assistant
- Source system read-only access preserved for historical lookups
Cutover steps:
- Send company-wide communication (24 hours before)
- Disable new bookings in source system
- Enable Navan SSO for all users
- Activate all Navan travel policies
- Switch corporate card feeds to Navan
- Verify first production bookings succeed
- Monitor error rates for 48 hours
Phase 6 — Post-Migration (Weeks 7-10)
- Monitor Navan API health daily for first two weeks
- Track user adoption metrics (login rate, booking volume, Ava usage)
- Collect feedback from frequent travelers and approvers
- Maintain source system in read-only mode for 90 days (historical reference)
- Decommission source system after retention period
Output
- Migration project plan with phase timelines and owners
- Data mapping document (source fields to Navan structure)
- User provisioning report showing successful account creation
- Parallel running reconciliation results
- Go/no-go checklist with sign-offs
- Post-migration adoption metrics
Error Handling
| Issue | Impact | Resolution |
|---|---|---|
| SCIM provisioning fails | Users cannot access Navan | Fall back to CSV upload; check IdP connector logs |
| SSO login fails | Users locked out | Verify SAML metadata; test with Navan admin account |
| Policy mismatch | Out-of-policy bookings approved | Audit first 50 bookings; adjust policy rules |
API returns 403 on | Cannot verify provisioning | Confirm API integration enabled in Admin > Integrations |
| Data sync not running | No reporting data | Check Fivetran/Airbyte connector status and credentials |
Examples
Quick migration readiness assessment:
# Verify Navan API access and user count echo "=== Migration Readiness Check ===" TOKEN=$(curl -s -X POST "https://api.navan.com/ta-auth/oauth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials&client_id=$NAVAN_CLIENT_ID&client_secret=$NAVAN_CLIENT_SECRET" \ | jq -r '.access_token') echo "API Auth: $([ -n "$TOKEN" ] && echo 'OK' || echo 'FAILED')" USERS=$(curl -s -H "Authorization: Bearer $TOKEN" \ "https://api.navan.com/v1/users" | jq '.data | length') echo "Provisioned users: $USERS" BOOKINGS=$(curl -s -H "Authorization: Bearer $TOKEN" \ "https://api.navan.com/v1/bookings?page=0&size=50" | jq '.data | length') echo "Total bookings: $BOOKINGS"
Resources
- Navan Help Center — Admin setup guides and migration support
- Navan Integrations — ERP and data connector options
- Navan Security — SOC 2, ISO 27001, GDPR compliance for vendor evaluation
Next Steps
- Use
to set up OAuth credentials for the migrationnavan-install-auth - Use
before cutover to validate production readinessnavan-prod-checklist - Use
to configure Fivetran/Airbyte data pipelinesnavan-data-sync