Chapter 10 · ProjectVIEW ERP Master SaaS Framework Chapter 10 governs what happens when a ProjectVIEW ERP version reaches end-of-life: at least 12 months’ notice, migration services, adoption of integrations and customisations, re-training and change management. Whether the customer moves to the successor version or ends the subscription, data is returned within 2 business days of a written request (SQL backup, CSV, JSON or XML) and the environment is decommissioned under a defined process — “no customer left behind”. 12 monthsminimum EOL notice 2 BDdata return after written request .bak · CSV · JSON · XMLexport formats 10.1 Overview & Purpose This chapter establishes the comprehensive framework governing the end-of-life (EOL) lifecycle of the ProjectVIEW ERP Platform, including major-version transitions, migration services, re-training obligations, integration and customisation adoption, data-return rights, and subscription-cessation procedures. It supersedes and expands upon the summary provisions of Chapter 4, §4.7.4. The Provider’s EOL framework is modelled on the mature version-transition practices of leading enterprise SaaS and ERP vendors — including SAP S/4HANA, Oracle Fusion Cloud, IFS Cloud, and Infor CloudSuite — adapted to the Provider’s dedicated private sovereign deployment model and the Customer’s right to full data ownership (Chapter 9, §9.9). The core design principle is no Customer left behind : every Customer shall receive adequate notice, comprehensive migration support, re-training, and data-return services regardless of whether they elect to transition to the successor version or to terminate the subscription. 10.2 Scope This chapter covers: (a) Version lifecycle phases: General Availability (GA), Mainstream Support, Extended Support, End of Engineering (EOE), and End of Life (EOL) for each major version of the Platform. (b) Migration services: Provider-led data migration, schema transformation, environment provisioning, and cutover planning for Customers transitioning to a successor version. (c) Re-training & change management: Mandatory training programmes, Champion re-certification, user-adoption workshops, and knowledge-base updates required for a successful version transition. (d) Integration & customisation adoption: Assessment, re-engineering, and validation of Customer-specific integrations, customisations, and configurations on the successor version. (e) Data return for non-upgrading Customers: Data-export obligations, format specifications, delivery timelines, and chain-of-custody documentation for Customers electing not to transition. (f) Subscription cessation: Formal procedures for service wind-down, environment decommissioning, and contractual termination. (g) Roles & responsibilities: RACI allocation for all EOL activities across Provider and Customer organisations. This chapter does not cover incremental releases/updates within a major version (see Chapter 4, §4.7.1) or COTS platform upgrades performed during Mainstream Support (see Chapter 4, §4.7.3). 10.3 Version Lifecycle Phases Each major version of the Platform (e.g., v11, v12) progresses through a defined lifecycle. The Provider’s lifecycle model draws upon the version-support frameworks published by SAP (Maintenance Strategy), Oracle (Sustaining Support), IFS (Mainstream/Extended Maintenance), and Infor (Product Lifecycle Policy), adapted to the Provider’s SaaS-only delivery model: Phase Duration What the Customer Receives Provider Obligations General Availability (GA) Ongoing until successor GA Full access to all Platform features, modules, and APIs. Incremental releases (v11.01, v11.02…) delivered via Agile sprints (§4.7.1). Active development, feature enhancements, bug fixes, security patches, COTS currency maintenance. EOL Announcement T− 12 months Formal written notice that the current major version will reach End of Life. Notice specifies successor version, indicative migration timeline, and available transition services. Publish EOL Announcement. Commence successor-version readiness assessment for each Customer. Transition Window T− 12 months to T− 30 days Migration planning, data-migration execution, re-training, integration re-engineering, UAT on successor version, and parallel running (where elected). Deliver Migration Services, Training, and Integration Adoption as defined in §10.5– §10.7. End of Engineering (EOE) T− 30 days No new Change Requests accepted. Technical Support continues (Incident resolution + security patches only). Continue security-patch delivery and P1/P2 Incident resolution for the legacy version. End of Life (EOL) T = 0 (12 months after Announcement) All support for the legacy version ceases. The Customer must be operating on the successor version or have elected Subscription Cessation. Decommission legacy environment. Execute data return if Customer has elected cessation (§10.9). Extended Support (optional) Up to 12 months post-EOL Available upon written request and subject to additional fees. Provides P1/P2 Incident resolution and critical security patches only. No feature development. Deliver Extended Support under a separate Extended Support Addendum to the Commercial Contract. Key commitment: The Provider guarantees a minimum of twelve (12) months between the EOL Announcement and the EOL Date. No Customer shall be required to transition in less than 12 months from the date of formal written notice. This aligns with best practice as observed across SAP, Oracle, IFS, and Infor lifecycle policies. 10.4 EOL Announcement & Customer Communication The Provider shall communicate the EOL lifecycle to each Customer through the following structured programme: Communication Timing Channel Content EOL Announcement Letter T− 12 months (minimum) Written notice to Customer’s designated contact + Account Manager email Formal EOL date, successor version identification, summary of migration services, indicative timeline, and Customer action required. Migration Readiness Assessment T− 11 months Joint workshop (remote or on-site) Impact assessment of Customer-specific integrations, customisations, and data volumes. Preliminary migration plan and resource requirements. Quarterly Transition Status Updates T−‒9, T−6, T−3 months Service Review meeting + written report Migration progress, outstanding actions, risk register, training schedule, and projected cutover date. EOE Notice T− 30 days Written notice + in-application banner Confirmation that new Change Requests will no longer be accepted for the legacy version. Support scope reduction notice. Final Migration Confirmation T− 14 days Written notice Confirmation of completed migration (or Customer election for cessation + data return). Final cutover logistics. EOL Confirmation T = 0 Written notice Legacy version decommissioned. Successor version is the sole supported version. Extended Support availability confirmed (if applicable). 10.5 Migration Services The Provider shall deliver a structured migration programme for each Customer transitioning to the successor version. Migration services are included in the subscription at no additional cost for the standard migration scope defined below. Enhanced migration services (e.g., legacy-system data ingestion, complex ETL transformations, parallel running beyond the standard period) are available as separately scoped engagements. 10.5.1 Standard Migration Scope (a) Environment provisioning: The Provider shall provision a successor-version environment within the Customer’s dedicated private sovereign Azure tenant, configured with the same security controls, networking, and compliance settings as the existing production environment. (b) Data migration: Full migration of all Customer Data from the legacy-version database to the successor-version database, including master data, transactional data, configuration data, and audit trails. The Provider shall use automated schema-transformation scripts validated against the Customer’s data profile. (c) Data cleansing advisory: Consistent with Oracle Fusion and Infor CloudSuite best practice, the Provider shall advise the Customer on data-cleansing opportunities prior to migration. The recommended approach is to migrate no more than three (3) years of active transactional data, with historical data archived in a read-only format accessible for reporting and compliance. (d) Configuration migration: All Customer-specific configurations (roles, workflows, approval chains, notification rules, report templates, dashboards) are migrated to the successor version using the Provider’s configuration-export/import tooling. (e) Migration testing: A minimum of two (2) full migration rehearsals shall be executed in the Staging Environment prior to production cutover. Each rehearsal includes data-integrity verification (referential, computational, temporal), application-layer smoke testing, and performance benchmarking. (f) Cutover execution: Production cutover to the successor version during a pre-agreed maintenance window, including DNS/network transition, database switchover, post-cutover verification, and rollback readiness. (g) Hypercare period: A minimum of thirty (30) calendar days of dedicated post-migration hypercare support, during which the Provider shall assign a Migration Lead and dedicated support resources for priority incident resolution and stabilisation. 10.5.2 Data Migration Integrity Assurance The Provider shall apply the following data-integrity controls throughout the migration process, aligned with the AI-augmented testing framework defined in Chapter 5 (Software Quality & Testing): (a) Pre-migration baseline: A cryptographic hash (SHA-256) of the complete database and row-count inventory is captured immediately prior to migration commencement, establishing the data-integrity baseline. (b) Post-migration reconciliation: Row-count reconciliation, referential-integrity assertions, and computational-integrity checks are executed against the successor-version database. The post-migration hash is compared against the pre-migration baseline. (c) AI-agent validation (optional): Where the Customer has elected the AI-Augmented Testing service (Chapter 5), the Provider shall deploy AI agents against the successor-version environment to execute end-to-end simulation scenarios, validating data flows, business rules, and integration points. (d) Migration sign-off: The Customer shall conduct UAT on the successor-version environment. Written Customer sign-off is required prior to production cutover, consistent with the UAT requirements defined in Chapter 5, §5.8. 10.6 Integration & Customisation Adoption Major-version transitions may affect Customer-specific integrations, customisations, and third-party extensions. The Provider shall manage this transition through a structured adoption programme: 10.6.1 Integration Impact Assessment Within thirty (30) calendar days of the EOL Announcement, the Provider shall deliver to the Customer an Integration Impact Assessment covering: (a) API compatibility analysis: Mapping of all Customer-facing APIs used in the legacy version to their equivalents in the successor version, identifying breaking changes, deprecated endpoints, and new capabilities. (b) Third-party integration inventory: Catalogue of all active integrations (middleware, B2G connectors, shipping APIs, banking interfaces, third-party reporting tools) with compatibility status for the successor version. (c) Customisation registry: Complete inventory of Customer-specific customisations (compiled DLLs, custom SQL functions, bespoke reports, workflow extensions) with migration-path classification: (i) forward-compatible, (ii) requires re-engineering, (iii) deprecated / replacement available. (d) Effort estimate & timeline: Indicative effort (person-days) and timeline for re-engineering non-compatible integrations and customisations, distinguishing between standard scope (included) and enhanced scope (separately quoted). 10.6.2 Re-Engineering & Validation For integrations and customisations classified as “requires re-engineering”: (a) Provider-managed re-engineering: Where the customisation was originally built by the Provider (recorded in the Git repository under the Customer’s Client Branch), the Provider shall re-engineer and test the component at no additional cost as part of the standard migration scope. (b) Customer-managed or third-party integrations: Where the integration was built by the Customer or a third party, the Provider shall (i) provide technical documentation for the successor-version API surface, (ii) make the Staging Environment available for testing, and (iii) offer optional professional-services assistance on a time-and-materials basis. (c) Integration regression testing: All migrated integrations shall be subject to automated regression testing in the Staging Environment prior to production cutover, using the AI-agent framework (Chapter 5) or manual test scripts as agreed. 10.7 Re-Training & Change Management A major-version transition constitutes a Significant Platform Change and triggers mandatory re-training obligations under Chapter 6 (Training & Knowledge Transfer). The Provider shall deliver a tailored transition-training programme encompassing: 10.7.1 Training Needs Re-Assessment Within sixty (60) calendar days of the EOL Announcement, the Provider shall conduct a Training Needs Re-Assessment (TNRA) to identify: (a) New or changed UI elements, workflows, and navigation patterns in the successor version. (b) Deprecated features and their replacements. (c) New capabilities enabled by the successor version (including AI-driven features where applicable). (d) Role-specific training requirements based on the Customer’s active module configuration and organisational structure. The TNRA output is a Transition Training Plan, annexed to the Migration Plan, specifying sessions, durations, delivery methods, and target audiences. 10.7.2 Transition Training Programme Training Component Audience Format Timing Duration What’s New Briefing All Authorised Users Webinar (recorded + AI-transcribed) T−6 months 90 minutes Hands-On Workshop: Core Changes Super Users + Champions Instructor-led (online or on-site) T−5 to T−4 months 2–3 days per module group Champion Re-Certification DANAOS ProjectVIEW ERP Champions Instructor-led + examination T−4 to T−3 months 1 day per Champion Integration & API Workshop Customer IT / Integration team Technical workshop (online) T−4 months 1 day UAT Guidance Session UAT participants Instructor-led briefing T−2 months Half day Go-Live Readiness Check Champions + Customer IT Lead Checkpoint meeting T−14 days 2 hours Post-Migration Drop-In Clinics All Authorised Users Online Q&A (bi-weekly) T + 0 to T + 90 days 1 hour per session All transition training sessions shall be recorded and AI-transcribed in accordance with Chapter 6, §6.4.4. Recordings and transcripts shall be published to the Customer’s Per-Client Training Wiki (https://docs.projectview.wiki/[client]) within five (5) Business Days of each session. 10.7.3 Knowledge-Base Updates The Provider shall update the following knowledge resources prior to production cutover on the successor version: (a) Per-Client Training Wiki: All module-specific pages, process guides, and FAQ articles updated to reflect successor-version UI, workflows, and terminology. (b) Platform Release Centre: Release notes, deployment guides, and configuration references for the successor version published at. (c) In-application guidance: Contextual tooltips, help links, and AI-assisted prompts updated to reference successor-version functionality. 10.8 Customer Decision: Transition or Cessation No later than six (6) months before the EOL Date (i.e., T−6 months), the Customer shall formally notify the Provider of its election to either: (a) Option A — Transition: Proceed with migration to the successor version. The Provider delivers Migration Services (§10.5), Integration Adoption (§10.6), and Re-Training (§10.7). The subscription continues uninterrupted on the successor version under the existing commercial terms (unless varied by mutual written agreement). (b) Option B — Subscription Cessation: Elect not to transition. The Provider initiates the Subscription Cessation process (§10.9), including data return (§10.10), environment decommissioning (§10.11), and contractual termination (§10.12). The subscription terminates on the EOL Date (or the Extended Support expiry date, if elected). If the Customer fails to provide written notification by the T−6 deadline, the Provider shall issue a reminder notice. If no response is received within a further thirty (30) calendar days, the Provider shall deem the Customer to have elected Option A (Transition), and Migration Services shall proceed. 10.9 Subscription Cessation Process Where the Customer elects Option B (Subscription Cessation), the following process shall apply: Phase Timing Activity Owner 1. Cessation Notice T−6 months (Customer’s election) Customer provides written notice of intent not to transition. Provider acknowledges receipt within 2 Business Days. Customer → Account Manager 2. Cessation Planning T−6 to T−5 months Provider and Customer agree a Cessation Plan covering: data-export format(s), timeline, contact handover, open-ticket resolution, and environment wind-down schedule. Account Manager + Cloud Ops Lead 3. Data Export & Return T−5 to T−2 months Provider exports all Customer Data in agreed format(s) within 2 Business Days of each valid request (§10.10). Multiple export requests permitted. DBA + Cloud Ops 4. Customer Validation T−2 to T−1 month Customer validates completeness and integrity of exported data. Raises data-completeness objections (if any) within 14 calendar days of receipt. Customer IT Lead 5. Open-Ticket Resolution T−3 to T−30 days Provider resolves all open P1/P2 Incidents. Lower-priority tickets are closed with Customer agreement or documented as unresolved. Cloud Ops + Account Manager 6. Environment Decommissioning T = EOL Date Legacy environment is decommissioned: VM shutdown, database deletion, storage-account purge, encryption-key destruction (§10.11). Cloud Ops + DBA 7. Decommissioning Certificate T + 14 days Provider issues a Decommissioning Certificate confirming all Customer Data has been securely destroyed in accordance with NIST SP 800-88. CTO → Customer 8. Contractual Termination T + 30 days Agreement formally terminates. Surviving clauses (confidentiality, IP, limitation of liability, data-protection residual obligations) continue per §10.12. Legal / Account Manager 10.10 Data Return The Customer retains sole and exclusive ownership of all Customer Data at all times (Chapter 9, §9.9). Upon Subscription Cessation, the Provider’s data-return obligations are as follows: 10.10.1 Export Formats & Delivery (a) Standard export formats: SQL Server backup file (.bak), CSV, JSON, and/or XML. The Customer may request any combination of formats. (b) Delivery timeline: Within two (2) Business Days of receiving a valid written request from the Customer. (c) Delivery method: Encrypted secure transfer via the Customer’s designated SFTP endpoint, Azure Blob Storage SAS token, or physical encrypted media (courier-delivered with chain-of-custody documentation). (d) Scope of export: All Customer Data including: master data, transactional data, configuration data, audit trails, change-tracking records, document attachments (blob storage), and application-generated reports. (e) Multiple exports: The Customer may request multiple exports during the cessation period. Each request shall be fulfilled within 2 Business Days. 10.10.2 Data-Return Validation Following each data export: (a) Integrity hash: The Provider shall deliver a SHA-256 cryptographic hash of each exported data set, enabling the Customer to verify data integrity upon receipt. (b) Row-count certificate: The Provider shall deliver a row-count certificate listing the record count for each table/entity in the export, cross-referenced against the production database at the point-in-time of export. (c) Validation window: The Customer has fourteen (14) calendar days from receipt to raise a data-completeness or integrity objection. The Provider shall remediate and re-export within two (2) Business Days of any valid objection. (d) Deemed acceptance: If the Customer does not raise an objection within the 14-day validation window, the export shall be deemed accepted. 10.10.3 Cost of Data Return Data return within the standard scope (export in standard formats via secure digital transfer) is included in the subscription at no additional cost. The following services are available at additional cost on a time-and-materials basis: (a) Transformation of exported data into non-standard formats (e.g., target-system-specific schema transformations for ingestion into a successor ERP). (b) Physical media preparation and courier delivery. (c) Extended data-export window beyond the standard cessation timeline. (d) Technical advisory on data mapping, migration scripting, or ETL design for the Customer’s successor system. 10.11 Environment Decommissioning Upon completion of data return and expiry of the Customer’s validation window, the Provider shall decommission the Customer’s dedicated private sovereign environment: (a) Virtual machine shutdown: All Customer VMs (production and staging) are stopped, disk images deleted, and compute resources deallocated. (b) Database destruction: All SQL Server databases (production, staging, backups) are permanently deleted. Transaction logs and backup files in Azure Backup Vault are purged. (c) Storage-account purge: All Azure Blob Storage containers, file shares, and table storage associated with the Customer are permanently deleted, including GRS-replicated copies in the secondary region. (d) Encryption-key destruction: All Customer-specific encryption keys, secrets, and certificates in Azure Key Vault are purged (purge-protection override authorised by CTO). (e) Network cleanup: Virtual networks, NSGs, public IP addresses, DNS records, and SSL/TLS certificates associated with the Customer are deprovisioned. (f) CMDB update: All Customer-related configuration items are marked as decommissioned in the Provider’s CMDB. (g) Secure data destruction: All data destruction is performed in accordance with NIST SP 800-88 (Guidelines for Media Sanitisation). Azure’s cryptographic erasure ensures that data on decommissioned storage is irrecoverable. NIST SP 800-88 Rev. 1: Guidelines for Media Sanitization Azure Data Destruction 10.12 Surviving Obligations The following obligations survive the termination or expiry of the Framework and shall continue in full force and effect: (a) Confidentiality: Mutual confidentiality obligations survive for five (5) years from the date of termination (Chapter 8, §8.11). (b) Intellectual Property: All intellectual-property rights and licence restrictions survive indefinitely. (c) Data-protection residual obligations: Privacy obligations under Chapter 7 survive with respect to any Personal Data retained by the Provider pursuant to a legal or regulatory obligation (Chapter 7, §7.13). (d) Limitation of liability: Liability caps and exclusions continue to apply to claims arising from events during the Subscription Term. (e) Dispute resolution: The governing law and dispute-resolution provisions continue to apply to any claim arising out of or in connection with the Framework. (f) Audit rights: The Customer’s right to audit data-destruction compliance survives for twelve (12) months following the date of the Decommissioning Certificate. 10.13 Extended Support Option Consistent with the Extended Support models offered by SAP (Extended Maintenance), Oracle (Sustaining Support), IFS (Extended Maintenance), and Infor (Extended Maintenance), the Provider offers an optional Extended Support period for Customers who require additional time to complete their transition: (a) Availability: Extended Support must be requested in writing no later than sixty (60) calendar days before the EOL Date. (b) Duration: Up to twelve (12) months post-EOL Date, in quarterly increments. (c) Scope: P1 and P2 Incident resolution and critical security patches only. No feature development, no new Change Requests, no new module activations. (d) Pricing: Extended Support is charged at a premium of twenty percent (20%) above the then-current ARR, payable quarterly in advance. (e) Termination: Extended Support terminates automatically at the end of the elected period. All Subscription Cessation provisions (§10.9–§10.12) apply upon Extended Support expiry. 10.14 Roles & Responsibilities (RACI Matrix) The following RACI matrix allocates responsibilities for key EOL activities across Provider and Customer roles: Activity CTO Cloud Ops Lead Account Mgr DBA Lead Customer IT Lead Customer Champions EOL Announcement issuance A I R I I I Migration Readiness Assessment A R C R C I Integration Impact Assessment I R C C R I Data-migration execution I R I R C I Data-migration integrity verification I R I R C I Transition Training Programme delivery I C R I C R Champion Re-Certification I I R I C R Knowledge-base updates I R C I I C Integration re-engineering I R I C R I UAT on successor version I C C C R R Cutover planning & execution A R C R C I Customer decision (Transition / Cessation) I I C I R I Data-export fulfilment I R C R R I Data-return validation I I I I R I Environment decommissioning A R I R I I Decommissioning Certificate issuance R C I C I I Extended Support management A R C R I I Legend: R = Responsible · A = Accountable · C = Consulted · I = Informed. 10.15 Process Register The following process register catalogues all formal processes defined in this chapter. Process ID Process Name Trigger Handler Approver Outcome Section Ref. P-10.01 EOL Announcement Product roadmap decision to end-of-life a major version Account Manager CTO Written EOL Announcement delivered to all affected Customers ≥ 12 months before EOL Date. §10.4 P-10.02 Migration Readiness Assessment EOL Announcement issued (T−11 months) Cloud Ops + DBA CTO Customer-specific impact assessment and preliminary migration plan delivered. §10.4 P-10.03 Integration Impact Assessment EOL Announcement issued (within 30 days) Cloud Ops Lead CTO API compatibility analysis, integration inventory, customisation registry, and effort estimate delivered. §10.6.1 P-10.04 Training Needs Re-Assessment EOL Announcement issued (within 60 days) Account Manager CTO Transition Training Plan annexed to Migration Plan. §10.7.1 P-10.05 Data Migration Execution Migration Plan approved and Staging Environment provisioned DBA + Cloud Ops Cloud Ops Lead Customer Data migrated; integrity verified; rehearsal(s) completed. §10.5.1 P-10.06 Migration Integrity Verification Data migration rehearsal or production cutover completed DBA + Cloud Ops Cloud Ops Lead Pre/post hash comparison passed; row-count reconciliation complete; integrity report issued. §10.5.2 P-10.07 Integration Re-Engineering Integration classified as ‘requires re-engineering’ in Impact Assessment Cloud Ops Cloud Ops Lead Integration updated, tested, and validated on successor version. §10.6.2 P-10.08 Transition Training Delivery Transition Training Plan approved Account Manager + Trainers Cloud Ops Lead All scheduled training sessions delivered; recordings published to Wiki. §10.7.2 P-10.09 Champion Re-Certification Transition Training Programme scheduled Account Manager CTO Champions pass successor-version examination; certificates issued. §10.7.2 P-10.10 UAT on Successor Version Migration rehearsal passed; training completed Customer IT Lead + Champions Customer Written Customer sign-off on successor version obtained. §10.5.2 P-10.11 Production Cutover UAT sign-off received; cutover window agreed Cloud Ops + DBA CTO Production environment running successor version; rollback available for 72 hours. §10.5.1 P-10.12 Hypercare Support Production cutover completed Cloud Ops + DBA Account Manager 30-day hypercare period delivered; stabilisation confirmed. §10.5.1 P-10.13 Customer Cessation Election Customer written notice of intent not to transition Account Manager CTO Cessation Plan agreed; data-export schedule confirmed. §10.8 P-10.14 Data Export & Return Customer valid written request during cessation period DBA + Cloud Ops Account Manager Customer Data exported in agreed format within 2 Business Days. §10.10 P-10.15 Data-Return Validation Data export delivered to Customer Customer IT Lead Customer Customer confirms completeness within 14-day validation window (or deemed accepted). §10.10.2 P-10.16 Environment Decommissioning Data-return validation window expired; EOL Date reached Cloud Ops + DBA CTO All Customer resources destroyed per NIST SP 800-88; CMDB updated. §10.11 P-10.17 Decommissioning Certificate Environment decommissioning completed CTO CTO Decommissioning Certificate issued to Customer within 14 days. §10.11 P-10.18 Extended Support Activation Customer written request ≥60 days before EOL Date Cloud Ops Lead CTO Extended Support Addendum executed; P1/P2 support continued for elected period. §10.13 10.16 Process Flow Schematic The following nine-stage lifecycle illustrates the end-to-end flow of version transition and subscription cessation: ① EOL Announcement & Communication → ② Readiness & Impact Assessment → ③ Customer Decision (Transition / Cessation) ↓ TRANSITION PATH: ④ Migration & Re-Engineering → ⑤ Re-Training & Change Management → ⑥ UAT & Production Cutover ↓ CESSATION PATH: ⑦ Data Export & Return → ⑧ Environment Decommissioning → ⑨ Contractual Termination Stage ① EOL Announcement & Communication: The Provider issues the formal EOL Announcement ≥12 months before the EOL Date, initiating the structured communication programme (§10.4). All Customers receive written notice, and the Account Manager schedules the Migration Readiness Assessment (P-10.01). Stage ② Readiness & Impact Assessment: The Provider delivers the Migration Readiness Assessment, Integration Impact Assessment, and Training Needs Re-Assessment within 60 days of the EOL Announcement (P-10.02, P-10.03, P-10.04). Stage ③ Customer Decision: At T−6 months, the Customer formally elects to Transition (Option A) or Cessation (Option B). Default is Transition if no response within 30 days of reminder (P-10.13). Stage ④ Migration & Re-Engineering (Transition Path): Data migration, configuration migration, and integration re-engineering are executed in the Staging Environment with ≥2 rehearsals (P-10.05, P-10.06, P-10.07). Stage ⑤ Re-Training & Change Management (Transition Path): The Transition Training Programme is delivered: What’s New briefings, hands-on workshops, Champion re-certification, and knowledge-base updates (P-10.08, P-10.09). Stage ⑥ UAT & Production Cutover (Transition Path): Customer conducts UAT on successor version. Written sign-off triggers production cutover. 30-day Hypercare period follows (P-10.10, P-10.11, P-10.12). Stage ⑦ Data Export & Return (Cessation Path): The Provider exports all Customer Data within 2 Business Days of each valid request. Multiple exports permitted. Integrity hash and row-count certificate delivered with each export (P-10.14, P-10.15). Stage ⑧ Environment Decommissioning (Cessation Path): Upon validation-window expiry and EOL Date, the Provider destroys all Customer resources per NIST SP 800-88 and issues a Decommissioning Certificate (P-10.16, P-10.17). Stage ⑨ Contractual Termination (Cessation Path): The Framework formally terminates 30 days post-decommissioning. Surviving obligations (confidentiality, IP, data protection, liability, audit rights) continue per §10.12 (P-10.18 if Extended Support was active). ← PreviousBusiness Continuity & Disaster RecoveryNext →Architecture & Master Flows See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →
Chapter 10 · ProjectVIEW ERP Master SaaS Framework Chapter 10 governs what happens when a ProjectVIEW ERP version reaches end-of-life: at least 12 months’ notice, migration services, adoption of integrations and customisations, re-training and change management. Whether the customer moves to the successor version or ends the subscription, data is returned within 2 business days of a written request (SQL backup, CSV, JSON or XML) and the environment is decommissioned under a defined process — “no customer left behind”. 12 monthsminimum EOL notice 2 BDdata return after written request .bak · CSV · JSON · XMLexport formats 10.1 Overview & Purpose This chapter establishes the comprehensive framework governing the end-of-life (EOL) lifecycle of the ProjectVIEW ERP Platform, including major-version transitions, migration services, re-training obligations, integration and customisation adoption, data-return rights, and subscription-cessation procedures. It supersedes and expands upon the summary provisions of Chapter 4, §4.7.4. The Provider’s EOL framework is modelled on the mature version-transition practices of leading enterprise SaaS and ERP vendors — including SAP S/4HANA, Oracle Fusion Cloud, IFS Cloud, and Infor CloudSuite — adapted to the Provider’s dedicated private sovereign deployment model and the Customer’s right to full data ownership (Chapter 9, §9.9). The core design principle is no Customer left behind : every Customer shall receive adequate notice, comprehensive migration support, re-training, and data-return services regardless of whether they elect to transition to the successor version or to terminate the subscription. 10.2 Scope This chapter covers: (a) Version lifecycle phases: General Availability (GA), Mainstream Support, Extended Support, End of Engineering (EOE), and End of Life (EOL) for each major version of the Platform. (b) Migration services: Provider-led data migration, schema transformation, environment provisioning, and cutover planning for Customers transitioning to a successor version. (c) Re-training & change management: Mandatory training programmes, Champion re-certification, user-adoption workshops, and knowledge-base updates required for a successful version transition. (d) Integration & customisation adoption: Assessment, re-engineering, and validation of Customer-specific integrations, customisations, and configurations on the successor version. (e) Data return for non-upgrading Customers: Data-export obligations, format specifications, delivery timelines, and chain-of-custody documentation for Customers electing not to transition. (f) Subscription cessation: Formal procedures for service wind-down, environment decommissioning, and contractual termination. (g) Roles & responsibilities: RACI allocation for all EOL activities across Provider and Customer organisations. This chapter does not cover incremental releases/updates within a major version (see Chapter 4, §4.7.1) or COTS platform upgrades performed during Mainstream Support (see Chapter 4, §4.7.3). 10.3 Version Lifecycle Phases Each major version of the Platform (e.g., v11, v12) progresses through a defined lifecycle. The Provider’s lifecycle model draws upon the version-support frameworks published by SAP (Maintenance Strategy), Oracle (Sustaining Support), IFS (Mainstream/Extended Maintenance), and Infor (Product Lifecycle Policy), adapted to the Provider’s SaaS-only delivery model: Phase Duration What the Customer Receives Provider Obligations General Availability (GA) Ongoing until successor GA Full access to all Platform features, modules, and APIs. Incremental releases (v11.01, v11.02…) delivered via Agile sprints (§4.7.1). Active development, feature enhancements, bug fixes, security patches, COTS currency maintenance. EOL Announcement T− 12 months Formal written notice that the current major version will reach End of Life. Notice specifies successor version, indicative migration timeline, and available transition services. Publish EOL Announcement. Commence successor-version readiness assessment for each Customer. Transition Window T− 12 months to T− 30 days Migration planning, data-migration execution, re-training, integration re-engineering, UAT on successor version, and parallel running (where elected). Deliver Migration Services, Training, and Integration Adoption as defined in §10.5– §10.7. End of Engineering (EOE) T− 30 days No new Change Requests accepted. Technical Support continues (Incident resolution + security patches only). Continue security-patch delivery and P1/P2 Incident resolution for the legacy version. End of Life (EOL) T = 0 (12 months after Announcement) All support for the legacy version ceases. The Customer must be operating on the successor version or have elected Subscription Cessation. Decommission legacy environment. Execute data return if Customer has elected cessation (§10.9). Extended Support (optional) Up to 12 months post-EOL Available upon written request and subject to additional fees. Provides P1/P2 Incident resolution and critical security patches only. No feature development. Deliver Extended Support under a separate Extended Support Addendum to the Commercial Contract. Key commitment: The Provider guarantees a minimum of twelve (12) months between the EOL Announcement and the EOL Date. No Customer shall be required to transition in less than 12 months from the date of formal written notice. This aligns with best practice as observed across SAP, Oracle, IFS, and Infor lifecycle policies. 10.4 EOL Announcement & Customer Communication The Provider shall communicate the EOL lifecycle to each Customer through the following structured programme: Communication Timing Channel Content EOL Announcement Letter T− 12 months (minimum) Written notice to Customer’s designated contact + Account Manager email Formal EOL date, successor version identification, summary of migration services, indicative timeline, and Customer action required. Migration Readiness Assessment T− 11 months Joint workshop (remote or on-site) Impact assessment of Customer-specific integrations, customisations, and data volumes. Preliminary migration plan and resource requirements. Quarterly Transition Status Updates T−‒9, T−6, T−3 months Service Review meeting + written report Migration progress, outstanding actions, risk register, training schedule, and projected cutover date. EOE Notice T− 30 days Written notice + in-application banner Confirmation that new Change Requests will no longer be accepted for the legacy version. Support scope reduction notice. Final Migration Confirmation T− 14 days Written notice Confirmation of completed migration (or Customer election for cessation + data return). Final cutover logistics. EOL Confirmation T = 0 Written notice Legacy version decommissioned. Successor version is the sole supported version. Extended Support availability confirmed (if applicable). 10.5 Migration Services The Provider shall deliver a structured migration programme for each Customer transitioning to the successor version. Migration services are included in the subscription at no additional cost for the standard migration scope defined below. Enhanced migration services (e.g., legacy-system data ingestion, complex ETL transformations, parallel running beyond the standard period) are available as separately scoped engagements. 10.5.1 Standard Migration Scope (a) Environment provisioning: The Provider shall provision a successor-version environment within the Customer’s dedicated private sovereign Azure tenant, configured with the same security controls, networking, and compliance settings as the existing production environment. (b) Data migration: Full migration of all Customer Data from the legacy-version database to the successor-version database, including master data, transactional data, configuration data, and audit trails. The Provider shall use automated schema-transformation scripts validated against the Customer’s data profile. (c) Data cleansing advisory: Consistent with Oracle Fusion and Infor CloudSuite best practice, the Provider shall advise the Customer on data-cleansing opportunities prior to migration. The recommended approach is to migrate no more than three (3) years of active transactional data, with historical data archived in a read-only format accessible for reporting and compliance. (d) Configuration migration: All Customer-specific configurations (roles, workflows, approval chains, notification rules, report templates, dashboards) are migrated to the successor version using the Provider’s configuration-export/import tooling. (e) Migration testing: A minimum of two (2) full migration rehearsals shall be executed in the Staging Environment prior to production cutover. Each rehearsal includes data-integrity verification (referential, computational, temporal), application-layer smoke testing, and performance benchmarking. (f) Cutover execution: Production cutover to the successor version during a pre-agreed maintenance window, including DNS/network transition, database switchover, post-cutover verification, and rollback readiness. (g) Hypercare period: A minimum of thirty (30) calendar days of dedicated post-migration hypercare support, during which the Provider shall assign a Migration Lead and dedicated support resources for priority incident resolution and stabilisation. 10.5.2 Data Migration Integrity Assurance The Provider shall apply the following data-integrity controls throughout the migration process, aligned with the AI-augmented testing framework defined in Chapter 5 (Software Quality & Testing): (a) Pre-migration baseline: A cryptographic hash (SHA-256) of the complete database and row-count inventory is captured immediately prior to migration commencement, establishing the data-integrity baseline. (b) Post-migration reconciliation: Row-count reconciliation, referential-integrity assertions, and computational-integrity checks are executed against the successor-version database. The post-migration hash is compared against the pre-migration baseline. (c) AI-agent validation (optional): Where the Customer has elected the AI-Augmented Testing service (Chapter 5), the Provider shall deploy AI agents against the successor-version environment to execute end-to-end simulation scenarios, validating data flows, business rules, and integration points. (d) Migration sign-off: The Customer shall conduct UAT on the successor-version environment. Written Customer sign-off is required prior to production cutover, consistent with the UAT requirements defined in Chapter 5, §5.8. 10.6 Integration & Customisation Adoption Major-version transitions may affect Customer-specific integrations, customisations, and third-party extensions. The Provider shall manage this transition through a structured adoption programme: 10.6.1 Integration Impact Assessment Within thirty (30) calendar days of the EOL Announcement, the Provider shall deliver to the Customer an Integration Impact Assessment covering: (a) API compatibility analysis: Mapping of all Customer-facing APIs used in the legacy version to their equivalents in the successor version, identifying breaking changes, deprecated endpoints, and new capabilities. (b) Third-party integration inventory: Catalogue of all active integrations (middleware, B2G connectors, shipping APIs, banking interfaces, third-party reporting tools) with compatibility status for the successor version. (c) Customisation registry: Complete inventory of Customer-specific customisations (compiled DLLs, custom SQL functions, bespoke reports, workflow extensions) with migration-path classification: (i) forward-compatible, (ii) requires re-engineering, (iii) deprecated / replacement available. (d) Effort estimate & timeline: Indicative effort (person-days) and timeline for re-engineering non-compatible integrations and customisations, distinguishing between standard scope (included) and enhanced scope (separately quoted). 10.6.2 Re-Engineering & Validation For integrations and customisations classified as “requires re-engineering”: (a) Provider-managed re-engineering: Where the customisation was originally built by the Provider (recorded in the Git repository under the Customer’s Client Branch), the Provider shall re-engineer and test the component at no additional cost as part of the standard migration scope. (b) Customer-managed or third-party integrations: Where the integration was built by the Customer or a third party, the Provider shall (i) provide technical documentation for the successor-version API surface, (ii) make the Staging Environment available for testing, and (iii) offer optional professional-services assistance on a time-and-materials basis. (c) Integration regression testing: All migrated integrations shall be subject to automated regression testing in the Staging Environment prior to production cutover, using the AI-agent framework (Chapter 5) or manual test scripts as agreed. 10.7 Re-Training & Change Management A major-version transition constitutes a Significant Platform Change and triggers mandatory re-training obligations under Chapter 6 (Training & Knowledge Transfer). The Provider shall deliver a tailored transition-training programme encompassing: 10.7.1 Training Needs Re-Assessment Within sixty (60) calendar days of the EOL Announcement, the Provider shall conduct a Training Needs Re-Assessment (TNRA) to identify: (a) New or changed UI elements, workflows, and navigation patterns in the successor version. (b) Deprecated features and their replacements. (c) New capabilities enabled by the successor version (including AI-driven features where applicable). (d) Role-specific training requirements based on the Customer’s active module configuration and organisational structure. The TNRA output is a Transition Training Plan, annexed to the Migration Plan, specifying sessions, durations, delivery methods, and target audiences. 10.7.2 Transition Training Programme Training Component Audience Format Timing Duration What’s New Briefing All Authorised Users Webinar (recorded + AI-transcribed) T−6 months 90 minutes Hands-On Workshop: Core Changes Super Users + Champions Instructor-led (online or on-site) T−5 to T−4 months 2–3 days per module group Champion Re-Certification DANAOS ProjectVIEW ERP Champions Instructor-led + examination T−4 to T−3 months 1 day per Champion Integration & API Workshop Customer IT / Integration team Technical workshop (online) T−4 months 1 day UAT Guidance Session UAT participants Instructor-led briefing T−2 months Half day Go-Live Readiness Check Champions + Customer IT Lead Checkpoint meeting T−14 days 2 hours Post-Migration Drop-In Clinics All Authorised Users Online Q&A (bi-weekly) T + 0 to T + 90 days 1 hour per session All transition training sessions shall be recorded and AI-transcribed in accordance with Chapter 6, §6.4.4. Recordings and transcripts shall be published to the Customer’s Per-Client Training Wiki (https://docs.projectview.wiki/[client]) within five (5) Business Days of each session. 10.7.3 Knowledge-Base Updates The Provider shall update the following knowledge resources prior to production cutover on the successor version: (a) Per-Client Training Wiki: All module-specific pages, process guides, and FAQ articles updated to reflect successor-version UI, workflows, and terminology. (b) Platform Release Centre: Release notes, deployment guides, and configuration references for the successor version published at. (c) In-application guidance: Contextual tooltips, help links, and AI-assisted prompts updated to reference successor-version functionality. 10.8 Customer Decision: Transition or Cessation No later than six (6) months before the EOL Date (i.e., T−6 months), the Customer shall formally notify the Provider of its election to either: (a) Option A — Transition: Proceed with migration to the successor version. The Provider delivers Migration Services (§10.5), Integration Adoption (§10.6), and Re-Training (§10.7). The subscription continues uninterrupted on the successor version under the existing commercial terms (unless varied by mutual written agreement). (b) Option B — Subscription Cessation: Elect not to transition. The Provider initiates the Subscription Cessation process (§10.9), including data return (§10.10), environment decommissioning (§10.11), and contractual termination (§10.12). The subscription terminates on the EOL Date (or the Extended Support expiry date, if elected). If the Customer fails to provide written notification by the T−6 deadline, the Provider shall issue a reminder notice. If no response is received within a further thirty (30) calendar days, the Provider shall deem the Customer to have elected Option A (Transition), and Migration Services shall proceed. 10.9 Subscription Cessation Process Where the Customer elects Option B (Subscription Cessation), the following process shall apply: Phase Timing Activity Owner 1. Cessation Notice T−6 months (Customer’s election) Customer provides written notice of intent not to transition. Provider acknowledges receipt within 2 Business Days. Customer → Account Manager 2. Cessation Planning T−6 to T−5 months Provider and Customer agree a Cessation Plan covering: data-export format(s), timeline, contact handover, open-ticket resolution, and environment wind-down schedule. Account Manager + Cloud Ops Lead 3. Data Export & Return T−5 to T−2 months Provider exports all Customer Data in agreed format(s) within 2 Business Days of each valid request (§10.10). Multiple export requests permitted. DBA + Cloud Ops 4. Customer Validation T−2 to T−1 month Customer validates completeness and integrity of exported data. Raises data-completeness objections (if any) within 14 calendar days of receipt. Customer IT Lead 5. Open-Ticket Resolution T−3 to T−30 days Provider resolves all open P1/P2 Incidents. Lower-priority tickets are closed with Customer agreement or documented as unresolved. Cloud Ops + Account Manager 6. Environment Decommissioning T = EOL Date Legacy environment is decommissioned: VM shutdown, database deletion, storage-account purge, encryption-key destruction (§10.11). Cloud Ops + DBA 7. Decommissioning Certificate T + 14 days Provider issues a Decommissioning Certificate confirming all Customer Data has been securely destroyed in accordance with NIST SP 800-88. CTO → Customer 8. Contractual Termination T + 30 days Agreement formally terminates. Surviving clauses (confidentiality, IP, limitation of liability, data-protection residual obligations) continue per §10.12. Legal / Account Manager 10.10 Data Return The Customer retains sole and exclusive ownership of all Customer Data at all times (Chapter 9, §9.9). Upon Subscription Cessation, the Provider’s data-return obligations are as follows: 10.10.1 Export Formats & Delivery (a) Standard export formats: SQL Server backup file (.bak), CSV, JSON, and/or XML. The Customer may request any combination of formats. (b) Delivery timeline: Within two (2) Business Days of receiving a valid written request from the Customer. (c) Delivery method: Encrypted secure transfer via the Customer’s designated SFTP endpoint, Azure Blob Storage SAS token, or physical encrypted media (courier-delivered with chain-of-custody documentation). (d) Scope of export: All Customer Data including: master data, transactional data, configuration data, audit trails, change-tracking records, document attachments (blob storage), and application-generated reports. (e) Multiple exports: The Customer may request multiple exports during the cessation period. Each request shall be fulfilled within 2 Business Days. 10.10.2 Data-Return Validation Following each data export: (a) Integrity hash: The Provider shall deliver a SHA-256 cryptographic hash of each exported data set, enabling the Customer to verify data integrity upon receipt. (b) Row-count certificate: The Provider shall deliver a row-count certificate listing the record count for each table/entity in the export, cross-referenced against the production database at the point-in-time of export. (c) Validation window: The Customer has fourteen (14) calendar days from receipt to raise a data-completeness or integrity objection. The Provider shall remediate and re-export within two (2) Business Days of any valid objection. (d) Deemed acceptance: If the Customer does not raise an objection within the 14-day validation window, the export shall be deemed accepted. 10.10.3 Cost of Data Return Data return within the standard scope (export in standard formats via secure digital transfer) is included in the subscription at no additional cost. The following services are available at additional cost on a time-and-materials basis: (a) Transformation of exported data into non-standard formats (e.g., target-system-specific schema transformations for ingestion into a successor ERP). (b) Physical media preparation and courier delivery. (c) Extended data-export window beyond the standard cessation timeline. (d) Technical advisory on data mapping, migration scripting, or ETL design for the Customer’s successor system. 10.11 Environment Decommissioning Upon completion of data return and expiry of the Customer’s validation window, the Provider shall decommission the Customer’s dedicated private sovereign environment: (a) Virtual machine shutdown: All Customer VMs (production and staging) are stopped, disk images deleted, and compute resources deallocated. (b) Database destruction: All SQL Server databases (production, staging, backups) are permanently deleted. Transaction logs and backup files in Azure Backup Vault are purged. (c) Storage-account purge: All Azure Blob Storage containers, file shares, and table storage associated with the Customer are permanently deleted, including GRS-replicated copies in the secondary region. (d) Encryption-key destruction: All Customer-specific encryption keys, secrets, and certificates in Azure Key Vault are purged (purge-protection override authorised by CTO). (e) Network cleanup: Virtual networks, NSGs, public IP addresses, DNS records, and SSL/TLS certificates associated with the Customer are deprovisioned. (f) CMDB update: All Customer-related configuration items are marked as decommissioned in the Provider’s CMDB. (g) Secure data destruction: All data destruction is performed in accordance with NIST SP 800-88 (Guidelines for Media Sanitisation). Azure’s cryptographic erasure ensures that data on decommissioned storage is irrecoverable. NIST SP 800-88 Rev. 1: Guidelines for Media Sanitization Azure Data Destruction 10.12 Surviving Obligations The following obligations survive the termination or expiry of the Framework and shall continue in full force and effect: (a) Confidentiality: Mutual confidentiality obligations survive for five (5) years from the date of termination (Chapter 8, §8.11). (b) Intellectual Property: All intellectual-property rights and licence restrictions survive indefinitely. (c) Data-protection residual obligations: Privacy obligations under Chapter 7 survive with respect to any Personal Data retained by the Provider pursuant to a legal or regulatory obligation (Chapter 7, §7.13). (d) Limitation of liability: Liability caps and exclusions continue to apply to claims arising from events during the Subscription Term. (e) Dispute resolution: The governing law and dispute-resolution provisions continue to apply to any claim arising out of or in connection with the Framework. (f) Audit rights: The Customer’s right to audit data-destruction compliance survives for twelve (12) months following the date of the Decommissioning Certificate. 10.13 Extended Support Option Consistent with the Extended Support models offered by SAP (Extended Maintenance), Oracle (Sustaining Support), IFS (Extended Maintenance), and Infor (Extended Maintenance), the Provider offers an optional Extended Support period for Customers who require additional time to complete their transition: (a) Availability: Extended Support must be requested in writing no later than sixty (60) calendar days before the EOL Date. (b) Duration: Up to twelve (12) months post-EOL Date, in quarterly increments. (c) Scope: P1 and P2 Incident resolution and critical security patches only. No feature development, no new Change Requests, no new module activations. (d) Pricing: Extended Support is charged at a premium of twenty percent (20%) above the then-current ARR, payable quarterly in advance. (e) Termination: Extended Support terminates automatically at the end of the elected period. All Subscription Cessation provisions (§10.9–§10.12) apply upon Extended Support expiry. 10.14 Roles & Responsibilities (RACI Matrix) The following RACI matrix allocates responsibilities for key EOL activities across Provider and Customer roles: Activity CTO Cloud Ops Lead Account Mgr DBA Lead Customer IT Lead Customer Champions EOL Announcement issuance A I R I I I Migration Readiness Assessment A R C R C I Integration Impact Assessment I R C C R I Data-migration execution I R I R C I Data-migration integrity verification I R I R C I Transition Training Programme delivery I C R I C R Champion Re-Certification I I R I C R Knowledge-base updates I R C I I C Integration re-engineering I R I C R I UAT on successor version I C C C R R Cutover planning & execution A R C R C I Customer decision (Transition / Cessation) I I C I R I Data-export fulfilment I R C R R I Data-return validation I I I I R I Environment decommissioning A R I R I I Decommissioning Certificate issuance R C I C I I Extended Support management A R C R I I Legend: R = Responsible · A = Accountable · C = Consulted · I = Informed. 10.15 Process Register The following process register catalogues all formal processes defined in this chapter. Process ID Process Name Trigger Handler Approver Outcome Section Ref. P-10.01 EOL Announcement Product roadmap decision to end-of-life a major version Account Manager CTO Written EOL Announcement delivered to all affected Customers ≥ 12 months before EOL Date. §10.4 P-10.02 Migration Readiness Assessment EOL Announcement issued (T−11 months) Cloud Ops + DBA CTO Customer-specific impact assessment and preliminary migration plan delivered. §10.4 P-10.03 Integration Impact Assessment EOL Announcement issued (within 30 days) Cloud Ops Lead CTO API compatibility analysis, integration inventory, customisation registry, and effort estimate delivered. §10.6.1 P-10.04 Training Needs Re-Assessment EOL Announcement issued (within 60 days) Account Manager CTO Transition Training Plan annexed to Migration Plan. §10.7.1 P-10.05 Data Migration Execution Migration Plan approved and Staging Environment provisioned DBA + Cloud Ops Cloud Ops Lead Customer Data migrated; integrity verified; rehearsal(s) completed. §10.5.1 P-10.06 Migration Integrity Verification Data migration rehearsal or production cutover completed DBA + Cloud Ops Cloud Ops Lead Pre/post hash comparison passed; row-count reconciliation complete; integrity report issued. §10.5.2 P-10.07 Integration Re-Engineering Integration classified as ‘requires re-engineering’ in Impact Assessment Cloud Ops Cloud Ops Lead Integration updated, tested, and validated on successor version. §10.6.2 P-10.08 Transition Training Delivery Transition Training Plan approved Account Manager + Trainers Cloud Ops Lead All scheduled training sessions delivered; recordings published to Wiki. §10.7.2 P-10.09 Champion Re-Certification Transition Training Programme scheduled Account Manager CTO Champions pass successor-version examination; certificates issued. §10.7.2 P-10.10 UAT on Successor Version Migration rehearsal passed; training completed Customer IT Lead + Champions Customer Written Customer sign-off on successor version obtained. §10.5.2 P-10.11 Production Cutover UAT sign-off received; cutover window agreed Cloud Ops + DBA CTO Production environment running successor version; rollback available for 72 hours. §10.5.1 P-10.12 Hypercare Support Production cutover completed Cloud Ops + DBA Account Manager 30-day hypercare period delivered; stabilisation confirmed. §10.5.1 P-10.13 Customer Cessation Election Customer written notice of intent not to transition Account Manager CTO Cessation Plan agreed; data-export schedule confirmed. §10.8 P-10.14 Data Export & Return Customer valid written request during cessation period DBA + Cloud Ops Account Manager Customer Data exported in agreed format within 2 Business Days. §10.10 P-10.15 Data-Return Validation Data export delivered to Customer Customer IT Lead Customer Customer confirms completeness within 14-day validation window (or deemed accepted). §10.10.2 P-10.16 Environment Decommissioning Data-return validation window expired; EOL Date reached Cloud Ops + DBA CTO All Customer resources destroyed per NIST SP 800-88; CMDB updated. §10.11 P-10.17 Decommissioning Certificate Environment decommissioning completed CTO CTO Decommissioning Certificate issued to Customer within 14 days. §10.11 P-10.18 Extended Support Activation Customer written request ≥60 days before EOL Date Cloud Ops Lead CTO Extended Support Addendum executed; P1/P2 support continued for elected period. §10.13 10.16 Process Flow Schematic The following nine-stage lifecycle illustrates the end-to-end flow of version transition and subscription cessation: ① EOL Announcement & Communication → ② Readiness & Impact Assessment → ③ Customer Decision (Transition / Cessation) ↓ TRANSITION PATH: ④ Migration & Re-Engineering → ⑤ Re-Training & Change Management → ⑥ UAT & Production Cutover ↓ CESSATION PATH: ⑦ Data Export & Return → ⑧ Environment Decommissioning → ⑨ Contractual Termination Stage ① EOL Announcement & Communication: The Provider issues the formal EOL Announcement ≥12 months before the EOL Date, initiating the structured communication programme (§10.4). All Customers receive written notice, and the Account Manager schedules the Migration Readiness Assessment (P-10.01). Stage ② Readiness & Impact Assessment: The Provider delivers the Migration Readiness Assessment, Integration Impact Assessment, and Training Needs Re-Assessment within 60 days of the EOL Announcement (P-10.02, P-10.03, P-10.04). Stage ③ Customer Decision: At T−6 months, the Customer formally elects to Transition (Option A) or Cessation (Option B). Default is Transition if no response within 30 days of reminder (P-10.13). Stage ④ Migration & Re-Engineering (Transition Path): Data migration, configuration migration, and integration re-engineering are executed in the Staging Environment with ≥2 rehearsals (P-10.05, P-10.06, P-10.07). Stage ⑤ Re-Training & Change Management (Transition Path): The Transition Training Programme is delivered: What’s New briefings, hands-on workshops, Champion re-certification, and knowledge-base updates (P-10.08, P-10.09). Stage ⑥ UAT & Production Cutover (Transition Path): Customer conducts UAT on successor version. Written sign-off triggers production cutover. 30-day Hypercare period follows (P-10.10, P-10.11, P-10.12). Stage ⑦ Data Export & Return (Cessation Path): The Provider exports all Customer Data within 2 Business Days of each valid request. Multiple exports permitted. Integrity hash and row-count certificate delivered with each export (P-10.14, P-10.15). Stage ⑧ Environment Decommissioning (Cessation Path): Upon validation-window expiry and EOL Date, the Provider destroys all Customer resources per NIST SP 800-88 and issues a Decommissioning Certificate (P-10.16, P-10.17). Stage ⑨ Contractual Termination (Cessation Path): The Framework formally terminates 30 days post-decommissioning. Surviving obligations (confidentiality, IP, data protection, liability, audit rights) continue per §10.12 (P-10.18 if Extended Support was active). ← PreviousBusiness Continuity & Disaster RecoveryNext →Architecture & Master Flows See how ProjectVIEW ERP runs in a dedicated cloud environment for your projects. Book a Demo →