RISE with SAP vs. Traditional SAP: Which Approach Is Right for U.S. Businesses?

Compare RISE with SAP and traditional S/4HANA services: contracting, accountability, OpEx or CapEx, customization, innovation speed, and control.

For U.S. companies running SAP ERP, the decision to move to SAP S/4HANA involves more than choosing a deployment model. It affects the IT operating model, financial planning, vendor accountability, customization strategy, and the way finance and business systems are managed over time.

The timing also matters. SAP Business Suite 7 core applications, including eligible SAP ERP 6.0 releases with enhancement packages 6–8, are scheduled for mainstream maintenance through December 31, 2027. Optional extended maintenance is available through December 31, 2030. Earlier enhancement-package levels may already be in customer-specific maintenance, so organizations should confirm their exact SAP release and maintenance status against SAP's current maintenance strategy before setting a migration deadline.

Against this background, many U.S. organizations are comparing two broad approaches: RISE with SAP, which provides a guided path to SAP Cloud ERP Private with SAP-managed cloud services, and a traditional SAP S/4HANA model, where software, infrastructure, implementation, and operations can be sourced and managed separately.

Both approaches can support enterprise-scale transformation. The difference lies in the commercial structure, division of responsibilities, operating flexibility, and capabilities the organization wants to manage internally.

For U.S. businesses, the decision should also account for multi-entity finance, U.S. GAAP and group reporting, sales and use tax, banking integrations, SOX-related controls, and connections to the wider enterprise application landscape.

This guide compares the two models and outlines how to determine which approach best fits your business requirements.

RISE with SAP vs. Traditional SAP: Key Differences

RISE with SAP is a transformation offering designed to help organizations modernize their existing SAP ERP environments and move to SAP Cloud ERP Private. The offering combines a cloud ERP foundation with a guided transformation approach and a defined scope of SAP-managed services. Exact inclusions and responsibilities depend on the applicable contract and service description. 

A traditional SAP S/4HANA approach gives the customer more freedom to assemble the technology and service landscape. The company may purchase or subscribe to SAP software, select its infrastructure provider, appoint an implementation partner, and contract separately for ongoing support. This model can run on-premises or in the cloud, including on a hyperscaler.

The distinction is therefore not simply cloud versus on-premises. A traditional SAP environment can also be cloud-based. The key question is who contracts for, manages, and remains accountable for each part of the SAP landscape.

Neither model is automatically cheaper or more flexible in every situation. The right choice depends on the complexity of the SAP landscape, the organization's internal capabilities, contract terms, and the level of control it wants to retain.

1. Contracting Model and Operational Accountability

For U.S. organizations, vendor accountability is often one of the most important differences between RISE with SAP and a traditional SAP S/4HANA deployment.

RISE with SAP: A More Centralized Operating Model

RISE with SAP consolidates specified components of the ERP environment under a more integrated commercial arrangement. SAP manages the services included in the agreement and provides a defined route for escalating issues within that scope.

This can reduce the coordination burden for IT teams, especially when incidents involve the cloud infrastructure and technical services covered by the contract.

For example, a company may prefer a more centralized operating model because it does not want to coordinate separate infrastructure, database, hosting, and technical operations providers for every cross-layer incident.

However, a centralized contract does not mean that SAP assumes responsibility for every aspect of the ERP landscape.

The customer and its implementation or managed services partners still need to govern business processes, application configuration, custom development, integrations, data quality, testing, user access, and organizational change according to their respective responsibilities.

U.S. companies should therefore review the exact boundaries of SAP's service commitments before treating RISE as a complete outsourcing arrangement.

Traditional SAP: More Control, More Coordination

The traditional model allows a company to choose how each part of the landscape is sourced and managed.

For example, a business may deploy SAP S/4HANA on its own infrastructure, use a hyperscaler, engage a systems integrator for implementation, and work with a separate SAP application management services provider after go-live.

This approach provides more freedom to select vendors and negotiate service arrangements independently. It may be suitable for organizations with established enterprise architecture teams, mature IT service management, and existing infrastructure investments.

The trade-off is coordination.

When an incident affects several providers, the customer may have to establish ownership, coordinate troubleshooting, manage escalations, and resolve competing priorities. A managed service provider can reduce this burden, but doing so depends on the scope of its agreement and the responsibilities of the other vendors.

What U.S. decision-makers should ask: Who owns incident resolution, infrastructure availability, application support, integration failures, disaster recovery, and escalation when an issue crosses contractual boundaries?

The answer should be documented before the commercial model is selected.

2. Licensing, Subscription Costs, and Total Cost of Ownership

The financial comparison between RISE with SAP and traditional S/4HANA should go beyond the headline subscription price or license cost.

For CFOs, CIOs, and procurement teams, the objective is to understand how each option affects cash flow, long-term cost predictability, capital planning, and the flexibility to change vendors or technology components.

RISE with SAP: A Contracted Subscription Model

RISE with SAP brings specified software, cloud infrastructure, and managed services into a recurring commercial framework.

This can make budgeting more straightforward because several major cost categories are consolidated into a contract. It may also simplify internal chargeback and reduce the number of commercial relationships the organization has to manage.

The trade-off is that the customer needs to understand the full contractual scope. Additional software, integrations, implementation work, storage, environments, or other services may affect total expenditure depending on what the agreement includes.

Renewal terms, contract duration, price adjustments, growth assumptions, and exit provisions also matter. A subscription can make costs easier to forecast, but it does not guarantee that total cost of ownership will be lower.

Traditional SAP: Independent Cost Components

A traditional deployment separates more of the purchasing and operating decisions.

Depending on the arrangement, the organization may pay separately for SAP licenses or subscriptions, infrastructure, implementation, application support, security, upgrades, and third-party integrations.

This provides more opportunities to negotiate individual components, change providers, or optimize infrastructure costs. However, those opportunities require active commercial and operational governance.

Costs can also become less predictable when infrastructure consumption, support demand, custom development, or integration requirements change over time.

Cost Structure Comparison

Does RISE Automatically Mean OpEx While Traditional SAP Means CapEx?

No. The financial treatment depends on the contract, the nature of the costs, and the applicable accounting requirements.

A subscription model may change the timing and structure of payments, but U.S. companies should not assume every cost under RISE is automatically expensed or that every traditional SAP investment is capitalized.

Finance teams should evaluate software, hosting, implementation, configuration, and related expenditure with their accounting advisers under applicable U.S. GAAP.

For a reliable comparison, model the total cost of ownership across the entire planning horizon rather than comparing one annual subscription with an initial license quote.

3. U.S.-Specific Requirements That Can Change the Decision

The commercial model is only part of the decision. A deployment approach also needs to support the organization's U.S. business processes, compliance obligations, integration landscape, and future operating requirements.

U.S. Finance, Accounting, and Multi-Entity Operations

Many U.S. enterprises operate multiple legal entities, subsidiaries, distribution centers, business units, or acquired companies. Some also need to reconcile U.S. reporting requirements with a global corporate reporting framework.

The target SAP architecture may need to support U.S. GAAP, group accounting, intercompany processes, multiple currencies, consolidated reporting, and a standardized financial close.

These requirements should be considered during the initial solution design rather than treated as configuration details to resolve after the deployment model has been selected.

RISE may be attractive when an organization wants a more standardized cloud operating model. A traditional deployment may be preferable when the business needs a specific combination of infrastructure, application services, and integration arrangements.

The decisive factor is whether the chosen model supports the target finance architecture without introducing avoidable complexity.

Sales and Use Tax, Withholding, and Reporting

U.S. companies may need to integrate SAP with tax engines that support sales and use tax determination across applicable jurisdictions. Depending on the business, supplier withholding and 1099 reporting can also require carefully designed master data, reporting logic, and connections to external tax systems.

The deployment model should not be selected before these requirements are mapped.

The organization should confirm which tax capabilities are provided by SAP, which depend on third-party software, and who will maintain the interfaces and support them after go-live.

This is especially important when a company has a large customer base, multiple selling channels, acquisitions, or a complex tax technology landscape.

Banking, Treasury, and Payment Integrations

Treasury processes can involve ACH payments, check processing, Positive Pay, lockbox services, bank statement imports, payment approvals, and reconciliation.

These are operational dependencies, not minor technical details.

During a move to RISE or a traditional S/4HANA environment, the organization should establish how its bank connections will be hosted, monitored, tested, and supported. It should also identify which party is responsible when a payment file fails or a bank integration becomes unavailable.

A more centralized infrastructure arrangement may help simplify some technical responsibilities, but it does not eliminate the need to validate banking interfaces and business controls end to end.

SOX, Internal Controls, and Audit Readiness

For U.S. public companies subject to the relevant requirements, internal control over financial reporting must be considered throughout the ERP transformation. The SEC's guidance on Section 404 addresses management's assessment of internal control over financial reporting.

Moving infrastructure management to SAP does not transfer the organization's responsibility for its own financial reporting processes and controls.

The project should establish how it will maintain:

• segregation of duties;
• role design and access approvals;
• journal-entry controls;
• vendor and customer master-data governance;
• change management;
• approval workflows;
• audit trails and evidence retention;
• testing of key financial controls.

The responsibility for each control should be explicit. A provider's infrastructure security commitments should not be confused with the company's own obligations to operate effective business and financial controls.

Data Residency, Security, and Industry Requirements

U.S. organizations may face contractual, industry-specific, or internal requirements governing data location, access, security, retention, and recovery.

The important question is not simply whether a cloud provider operates data centers in the United States. Companies need to validate the actual deployment region, data-handling terms, access arrangements, recovery architecture, and relevant contractual commitments for their specific service.

Organizations in regulated industries or those supporting government contracts should also confirm whether the precise service scope meets their applicable security and compliance requirements. Standard cloud service commitments should not be assumed to satisfy every customer-specific obligation.

The U.S. Integration Landscape

SAP rarely operates in isolation. A U.S. enterprise may need to connect S/4HANA with CRM platforms, e-commerce applications, EDI networks, warehouses, third-party logistics providers, planning tools, tax systems, payroll, and reporting platforms.

The integration architecture should be assessed alongside the deployment model.

RISE can provide a defined cloud operating environment, but the responsibility for building, testing, monitoring, and maintaining integrations must still be assigned. A traditional approach can offer more freedom in how these connections are designed, while also increasing the number of components and providers the organization must coordinate.

For either option, the integration inventory should identify data ownership, interface dependencies, failure handling, monitoring, security, and recovery procedures. LeverX's SAP integration services can support this work across SAP and non-SAP environments.

4. Speed and Continuous Innovation

RISE with SAP is designed to provide a guided transformation path and a more integrated cloud operating model. SAP is also expanding its transformation toolchain and AI-assisted capabilities to support activities such as system analysis, custom-code assessment, data management, testing, and rollout planning. The capabilities available to a customer depend on the relevant offering and contract.

This can benefit U.S. companies that want a structured move from legacy ERP to SAP Cloud ERP Private and prefer to align their operating model with SAP's cloud roadmap.

The subscription itself, however, does not guarantee a faster implementation.

Project speed still depends on data quality, business decision-making, process standardization, custom-code complexity, integrations, and the availability of business and technical teams.

A traditional S/4HANA program can also move quickly when the organization has a clear target architecture, strong governance, and experienced implementation partners. It may offer more freedom to coordinate change and releases according to its own operational constraints.

The practical distinction is that RISE provides a more defined path and operating framework, while a traditional approach places more responsibility on the customer to coordinate the different elements.

For a U.S. company, the better choice is the one that fits its transformation capacity and business timeline - not necessarily the one with the most attractive modernization claims.

5. Customization, Standardization, and Clean Core

Customization is often a major consideration when moving from SAP ECC to S/4HANA.

Long-running SAP environments may contain years of ABAP development, custom reports, interfaces, enhancements, and workarounds. Some of these support genuine business differentiation. Others duplicate standard functionality or preserve processes that are no longer needed.

RISE with SAP: Modernize Within a Defined Cloud Model

RISE with SAP supports enterprise requirements through SAP Cloud ERP Private, but the environment operates within defined cloud service and technical boundaries.

The Clean Core approach helps organizations retain the business capabilities they need without carrying unnecessary modifications into the ERP core. Custom functionality can be evaluated for replacement with standard SAP capabilities, remediation, or redesign through approved extensions and integration patterns.

SAP Business Technology Platform (SAP BTP) can support side-by-side extensions, integration, and application development where appropriate. LeverX's SAP BTP services can help organizations design and build extensions while keeping the core easier to maintain.

For U.S. enterprises, this approach can reduce the long-term burden of maintaining legacy customizations while preserving business-specific functionality.

The important point is that choosing RISE does not remove the need to assess custom code. Organizations still need to decide which developments are essential, which can be retired, and which should be redesigned.

Traditional SAP: Greater Architectural Independence

A traditional deployment offers more freedom to select infrastructure, implementation partners, and operational arrangements. It can also provide more control over technical decisions and the pace of changes.

That flexibility is valuable when an organization's architecture has unusual requirements, when existing infrastructure investments need to be retained, or when tightly integrated legacy applications are difficult to replace.

However, architectural freedom should not automatically translate into more customization.

Deep modifications can increase testing effort, complicate upgrades, and make future migrations more difficult. A traditional deployment can still benefit from Clean Core principles, standardized extensions, and documented development governance.

How to Decide on Customization

Before choosing either model, classify custom developments into three groups:

1. Retain: Business-critical functionality that cannot reasonably be replaced by standard capabilities.
2. Redesign: Functionality that should be simplified, standardized, integrated, or moved to an extension.
3. Retire: Obsolete developments that no longer provide sufficient business value.

The result should be a target-state architecture rather than a list of historical customizations that must be carried forward.

6. Operations, Support, and Service-Level Agreements

The deployment decision determines not only how the system is implemented, but also how it will be operated after go-live.

What to Verify Under RISE with SAP

A RISE agreement should be reviewed in detail to establish which services are included, which services remain the customer's responsibility, and how performance is measured.

U.S. IT leaders should confirm:

• service availability commitments;
• incident severity definitions and response processes;
• infrastructure and technical operations responsibilities;
• backup and disaster recovery scope;
• recovery time and recovery point objectives;
• planned maintenance arrangements;
• access to logs and technical evidence;
• responsibilities for application-level incidents;
• support for integrations and third-party components;
• escalation procedures and service credits.

The organization should not assume that all application support, custom code, integrations, or non-SAP systems are covered simply because the core ERP environment is part of RISE.

What to Verify in a Traditional Model

A traditional deployment requires a similar review, but the responsibilities may be distributed among multiple providers.

The organization should determine who owns the service desk, application support, infrastructure, database administration, security monitoring, integrations, release management, and disaster recovery.

An application management services provider can help consolidate selected responsibilities. However, the company needs to ensure that service levels align across contracts and that someone owns issues that cross supplier boundaries.

For both models, the goal is the same: a transparent operating model with named service owners, realistic commitments, measurable outcomes, and a documented escalation path.

LeverX provides SAP Application Management Services to support ongoing SAP operations, incident resolution, performance optimization, and continuous improvement.

7. RISE with SAP vs. Traditional SAP: Which Model Fits Your Business?

There is no universal winner. The right choice depends on what the organization wants to optimize and how much operational responsibility it is prepared to retain.

When RISE with SAP May Be the Better Fit

Consider RISE with SAP when your organization:

• wants a guided path from legacy SAP ERP to SAP Cloud ERP Private;
• prefers a more centralized commercial and technical operating model;
• wants to reduce coordination across certain infrastructure and technical service providers;
• is prepared to standardize processes and follow the cloud service model;
• wants to align its transformation with SAP's cloud and innovation roadmap;
• values a recurring contract structure for the services in scope.

RISE may be particularly attractive to companies looking to modernize a large SAP landscape without continuing to manage every technical layer independently.

However, the organization should first validate the contracted service scope, custom-code requirements, integration responsibilities, and total cost over the expected contract term.

When Traditional SAP S/4HANA May Be the Better Fit

Consider a traditional approach when your organization:

• needs independent control over infrastructure and provider selection;
• has significant existing infrastructure investments;
• wants to negotiate software, hosting, implementation, and support separately;
• has mature internal teams capable of managing multiple vendors;
• needs a tailored deployment or operating arrangement;
• prioritizes the flexibility to optimize separate parts of the technology stack.

This model can be effective when the organization has the architecture, governance, and operational expertise to manage the added complexity.

It should not be chosen solely to preserve all existing customizations. Those developments still need to be evaluated against the target S/4HANA architecture.

A Practical Decision Matrix

The matrix is a starting point, not a recommendation based on one factor alone. For example, a business with complex U.S. controls may still choose RISE, provided it has a clear control framework and the services align with its requirements.

8. Questions to Ask Before Choosing RISE or Traditional SAP

The best way to compare the models is to turn broad preferences into specific commercial, architectural, and operational questions.

Contract and Accountability

• Which infrastructure, software, and technical services are included in the proposed RISE agreement?
• Which application, integration, and business-process responsibilities remain with our company or implementation partner?
• How are major incidents escalated when multiple systems or providers are involved?
• What happens when a service falls outside the contracted scope?

Cost and Commercial Flexibility

• What is the total expected cost over the initial contract term and at renewal?
• How are additional environments, capacity, storage, integrations, and services priced?
• What are the rules for price changes, contract expansion, and early termination?
• What data-extraction and transition assistance is provided if we change providers or deployment models?
• How should software, hosting, and implementation costs be treated under our U.S. accounting policies?

Architecture and Customization

• Which legacy customizations can be replaced by standard S/4HANA functionality?
• Which extensions should remain outside the core?
• How will SAP BTP and third-party applications fit into the target architecture?
• What freedom will we have to select integration services and other enterprise platforms?
• Which technical changes require SAP approval or need to follow a defined service process?

U.S. Operations and Compliance

• How will U.S. GAAP reporting and multi-entity finance requirements be supported?
• Which systems are responsible for sales and use tax, withholding, and 1099 reporting?
• How will ACH, Positive Pay, lockbox, and bank statement integrations be monitored and supported?
• How will SOX-relevant access, approval, change-management, and audit controls be tested?
• Which hosting region, security commitments, recovery objectives, and data-handling terms apply to our contract?

Long-Term Support

• Who provides application support after go-live?
• How are custom-code issues and third-party integration failures handled?
• What are the incident response and recovery commitments?
• Who owns upgrade planning, regression testing, and release readiness?
• How will service performance, costs, and business outcomes be reviewed over time?

These questions should be answered during vendor evaluation and reflected in the architecture, operating model, and commercial agreement.

9. How to Make the Transition Work

Whether an organization chooses RISE with SAP or a traditional S/4HANA approach, the transformation needs a structured plan.

Step 1: Assess the Current Landscape

Inventory the SAP release, custom code, data, interfaces, infrastructure, security roles, support arrangements, and operating costs.

For U.S. companies, also identify legal entities, financial reporting requirements, tax systems, banking dependencies, SOX-relevant controls, and connections to critical business applications.

Step 2: Define the Target Operating Model

Decide which responsibilities should be managed by SAP, the customer, and implementation or managed services partners.

Map service ownership across ERP applications, infrastructure, integrations, security, data, and business processes. Make sure the operating model reflects actual contract boundaries.

Step 3: Compare Commercial and Technical Options

Evaluate RISE with SAP and traditional deployment against the same business assumptions.

Include migration costs, software and cloud services, support, testing, custom-code remediation, integration, training, disaster recovery, and exit or transition costs.

Avoid comparing a full RISE quote with a traditional estimate that excludes ongoing operations - or vice versa.

Step 4: Design for U.S. Requirements

Validate finance, accounting, tax, banking, data handling, controls, and integration requirements before finalizing the solution design.

Confirm that relevant responsibilities have owners and that controls can be tested using the planned architecture and operational processes.

Step 5: Plan Migration, Testing, and Cutover

Use a structured implementation methodology such as SAP Activate to organize assessment, design, configuration, migration, testing, deployment, and stabilization.

Build test scenarios around complete business processes - not just ERP transactions. For example, validate the flow from a customer order to invoicing and accounting, or from a supplier invoice to payment file creation and bank reconciliation.

Step 6: Establish Post-Go-Live Governance

After deployment, monitor service levels, incident patterns, system performance, cost trends, integration reliability, control effectiveness, and business outcomes.

The target operating model should continue to evolve as the organization standardizes processes, retires legacy dependencies, and expands automation.

For organizations evaluating their migration options, LeverX's SAP S/4HANA migration services can support assessment, planning, execution, and the transition to a modern ERP environment.

The Strategic Choice That Actually Matters

The difference between RISE with SAP and a traditional SAP S/4HANA deployment is not simply whether the ERP runs in the cloud.

It is how the organization wants to contract for technology, assign responsibility, manage costs, and operate the platform after go-live.

RISE with SAP can provide a more integrated commercial and technical operating model, with defined SAP-managed services and a guided transformation path. A traditional deployment can offer greater independence in provider selection, infrastructure decisions, and operational design.

For U.S. businesses, these differences need to be evaluated alongside finance, tax, banking, internal controls, data requirements, and the wider enterprise application landscape.

The most effective decision comes from a realistic assessment of the organization's priorities and capabilities - not from assuming that either deployment model is universally better.

Choose RISE with SAP when the value of a more centralized cloud operating model outweighs the need for independent control over each technology layer. Choose traditional SAP when your business has the capabilities and requirements to benefit from a more independently managed landscape.

Whichever path you take, define the target architecture, clarify every provider's responsibilities, and build a business case around total cost of ownership and measurable operational outcomes.

How LeverX Can Help

LeverX helps organizations plan and execute SAP transformations, from the initial assessment and migration strategy to implementation, integration, and ongoing support.

Our teams help businesses evaluate deployment models, reduce legacy complexity, define Clean Core strategies, and align the SAP landscape with finance, operations, data, and integration requirements.

For U.S. companies, this includes accounting for multi-entity environments, critical enterprise interfaces, internal controls, and the operational responsibilities that extend beyond the ERP platform itself.

Whether you are evaluating RISE with SAP or a traditional S/4HANA deployment, the first step is to establish which model fits your business requirements, governance capabilities, and long-term operating objectives.

Discuss Your SAP Strategy

Frequently Asked Questions

What is the main difference between RISE with SAP and traditional SAP?

RISE with SAP combines SAP Cloud ERP Private with a defined scope of cloud services and a guided transformation approach. A traditional SAP S/4HANA model gives the customer more freedom to source and manage software, infrastructure, implementation, and support separately.

Is RISE with SAP always cheaper than traditional SAP?

No. Total cost depends on the contract, migration scope, infrastructure requirements, integrations, support, customization, and operating model. Compare both approaches over the same time horizon and include implementation, ongoing operations, renewal, and transition costs.

Is RISE with SAP a fully managed ERP service?

RISE includes SAP-managed services within the scope of the relevant agreement. It does not automatically transfer responsibility for every application, integration, customization, business process, or internal control. Customers should review the contract and responsibility boundaries carefully.

Can traditional SAP S/4HANA run in the cloud?

Yes. A traditional deployment can use a hyperscaler or other cloud infrastructure. The main distinction from RISE is the commercial arrangement and the division of responsibility, not simply the location where SAP runs.

Which option is better for U.S. companies subject to SOX requirements?

Either model can support a SOX-relevant environment. The organization must define and test its financial reporting controls, access management, approvals, change processes, and audit evidence regardless of who manages the underlying infrastructure.

How should U.S. companies compare the cost of RISE with traditional SAP?

Compare the total cost over the expected contract and operating period. Include software, infrastructure, migration, integrations, application support, security, testing, training, internal governance, renewal terms, and exit costs. Finance teams should also validate the applicable U.S. GAAP treatment of the proposed arrangements.

Can RISE with SAP support extensive customization?

RISE with SAP Cloud ERP Private supports enterprise customization within defined technical and service boundaries. Organizations should evaluate legacy ABAP and other modifications, determine which are essential, and consider standard functionality or approved extensions for the rest.

What U.S.-specific requirements should be considered before selecting a model?

Key considerations include U.S. GAAP and group reporting, multi-entity finance, sales and use tax, withholding and 1099 reporting, ACH and banking interfaces, SOX-relevant controls, data-handling requirements, and integrations with U.S. business systems.

Can a company change from traditional SAP to RISE later?

A move may be possible, but the effort depends on the current architecture, software rights, custom code, data, integrations, and contract arrangements. Organizations should evaluate transition complexity and costs before committing to a long-term model.

How does LeverX help businesses choose between RISE and traditional SAP?

LeverX supports SAP transformation planning and delivery, including landscape assessment, migration strategy, architecture, integration, custom-code evaluation, implementation, and ongoing services. The appropriate approach depends on the organization's technical, operational, commercial, and compliance requirements.

Disclaimer: This article is for informational purposes only and does not constitute legal, financial, tax, accounting, or technology procurement advice. RISE with SAP offerings, service scope, pricing, licensing terms, and maintenance policies may change and vary by contract, deployment model, and customer requirements. Cost comparisons and recommendations should be assessed against your organization's specific needs and current SAP documentation. Consult qualified advisors and review the applicable contractual terms before making a decision.