GROW with SAP custom development

Moving to GROW with SAP is one of the most strategic decisions a mid-size or growing business can make in 2025–26. But here is a reality that most SAP consultants in India will tell you — the journey is rarely straightforward, especially when your current ERP system is loaded with years of custom code, bolt-on modifications, and business-specific enhancements.

If you have been running SAP ECC or SAP Business One with heavy customisation, you already know what we mean. Your team has spent years — and significant budget — building workflows, reports, and integrations tailored to your specific operations. And now, the move to GROW with SAP (which sits on SAP S/4HANA Cloud, Public Edition) asks you to rethink all of that.

This blog breaks down everything you need to know about handling custom developments during a GROW with SAP migration — from understanding what is actually allowed in the cloud, to building a practical SAP clean core strategy, to migrating your custom ABAP logic to SAP BTP (Business Technology Platform).

GROW with SAP runs on SAP S/4HANA Public Cloud (Public Edition), which restricts custom ABAP code inside the core system. All custom developments must be moved to SAP BTP using clean core principles — keeping the ERP core clean, stable, and upgrade-safe while extending functionality via APIs, BTP extensions, and side-by-side integrations.

What Is GROW with SAP — And Why Does Customisation Become a Problem?

GROW with SAP is SAP’s cloud ERP offering specifically designed for fast-growing mid-market companies. It is built on SAP S/4HANA Public Cloud — a multi-tenant, standardised, and continuously updated environment. This is fundamentally different from the on-premise SAP ECC world where customers had root-level access to modify almost anything.

In the public cloud model, SAP maintains a single codebase for all customers. That means no custom ABAP programs directly inside the core. No Z-tables. No custom enhancements at the application layer. This is not a limitation — it is a design philosophy. SAP calls it the clean core strategy, and there are very good reasons behind it.

For Indian companies — especially in manufacturing, pharma, logistics, and retail — this creates a real planning challenge. Businesses in Pune, Ahmedabad, Mumbai, or Chennai often have localisation requirements, GST-specific workflows, regional vendor payment terms, or industry-specific MIS reports built into their current ERP. When you migrate to GROW with SAP, you cannot just copy-paste those customisations.

Indian companies migrating to GROW with SAP often face localisation challenges around GST return filing, e-invoicing integration (IRP/GSTN), TDS/TCS logic, and multi-entity reporting across Indian states. These are areas where custom ABAP migration to SAP BTP becomes critical to preserve compliance workflows.

Understanding SAP Clean Core Strategy Before You Migrate

Before your team can handle GROW with SAP custom development decisions, you need a firm understanding of what SAP’s clean core strategy actually means in practice. It is not just a buzzword — it is the guiding principle of the entire GROW with SAP architecture.

The Three Layers of the Clean Core Model

Core ERP (GROW with SAP): Standard SAP processes only — no custom code inside the system. Configuration is done through standard Customising (IMG) and Fiori-based Business Configuration.
Side-by-Side Extensions on SAP BTP: Custom logic, integrations, and enhancements live here. Think of it as your custom development sandbox that is separate from but connected to the ERP core.
Integration Layer: APIs, iFlows on SAP Integration Suite, and event-driven architecture connect the BTP extensions back to the GROW with SAP core and to third-party systems.

This architecture means that when Indian manufacturers or pharma companies need custom batch numbering logic, regulatory reporting, or dealer management workflows, those need to be rebuilt as BTP extensions — not as Z-programs inside the core.

The SAP clean core strategy gives you a significant advantage in the long run. Every time SAP releases a quarterly update to GROW with SAP, your core system upgrades automatically without breaking custom code. That is the payoff for doing the migration the right way.

Step-by-Step: How to Handle Custom Developments During Migration

Here is the framework we use at 2i Solutions when helping Indian businesses with SAP S/4HANA Cloud migration — specifically around custom development decisions.

Step 1 — Custom Code Discovery and Classification

The first step is always a thorough audit of all existing custom developments. This includes Z-programs, Y-tables, user exits, BADIs, enhancement spots, custom reports, interfaces, and any third-party add-ons sitting on top of your current SAP system.

SAP provides a tool called the Custom Code Migration App (available through SAP for Me) which analyses your custom objects and classifies them based on compatibility with SAP S/4HANA Cloud. Each object falls into one of these buckets:

Redundant: Already covered by standard SAP S/4HANA functionality — no migration needed.
Replaceable: A standard SAP alternative exists that needs configuration, not coding.
Migratable to BTP: Custom logic that has real business value and should be rebuilt as a BTP extension.
Retire: Legacy code that is no longer relevant to current business processes.

According to SAP’s own benchmarks, approximately 60–70% of custom developments in a typical ECC system can be handled by standard GROW with SAP functionality after proper configuration. The remaining 30–40% either need to be retired or migrated to SAP BTP as clean extensions.

Step 2 — Fit-to-Standard Workshops

Once you know what your custom code inventory looks like, the next step is running Fit-to-Standard (FTS) workshops. These are structured sessions where business process owners and SAP consultants walk through standard GROW with SAP processes side by side with your current workflows.

The goal is not to convince your team to abandon what works — it is to identify whether the standard SAP process, with proper configuration, can meet the same business outcome that your custom code was delivering. In most cases, it can. In some cases, it cannot — and that is when you plan a BTP extension.

Step 3 — Building a BTP Extension Roadmap

For the custom developments that genuinely need to survive, you build a custom ABAP migration to SAP BTP roadmap. This is not about lifting and shifting ABAP code — the BTP development environment is not ABAP-based. BTP extensions are typically built using:

SAP CAP (Cloud Application Programming Model) — Node.js or Java-based microservices
SAP Build Apps — Low-code/no-code UI extensions and workflows
SAP Integration Suite — For API-based integrations with third-party systems
SAP Datasphere or Analytics Cloud — For complex reporting that cannot live in the core

For Indian businesses, this often means rebuilding GST computation logic, MSME payment tracking (as per MSME Development Act timelines), or dealer portal integrations as BTP applications — clean, maintainable, and upgrade-safe.

Step 4 — Data Migration Strategy

SAP S/4HANA Cloud migration India projects often underestimate the data migration effort. When custom Z-tables are involved, you need to map legacy data to SAP-standard structures before migrating. SAP Migration Cockpit (LTMC) is the standard tool, but for complex transformations, custom ETL scripts on BTP may be needed.

For Indian companies with multi-entity structures — holding companies with subsidiaries across Maharashtra, Gujarat, Karnataka — data harmonisation across company codes, profit centres, and cost centres is a significant undertaking that needs dedicated planning.

Step 5 — Testing and Hypercare

Once extensions are built on BTP and the core is configured, rigorous testing is non-negotiable. This includes unit testing of BTP extensions, integration testing between BTP and GROW with SAP via APIs, user acceptance testing with actual business users, and performance testing under realistic Indian transaction volumes.

Post-go-live hypercare — typically 4 to 8 weeks — is essential to catch any issues in production that did not surface during testing. At 2i Solutions, we maintain a dedicated hypercare team for every GROW with SAP go-live.

Common Mistakes Indian Companies Make During GROW with SAP Custom Development Planning

Having worked on multiple SAP S/4HANA Cloud migration projects across India, we see the same mistakes come up repeatedly. Here are the ones that cause the most pain:

Trying to replicate ECC logic 1:1 in GROW with SAP — The cloud ERP works differently. Forcing old logic into a new system creates technical debt and defeats the purpose of moving to the cloud.
Underestimating BTP learning curve — SAP BTP is powerful but it requires skills in CAP, Node.js, or Java that most ABAP developers do not have out of the box. Budget for upskilling or partner support.
Skipping the clean core assessment — Jumping straight to development without auditing existing custom code leads to rework, delays, and scope creep.
Ignoring Indian localisation requirements early — GST, TDS, e-invoicing, and statutory reporting need to be part of the GROW with SAP migration plan from day one, not retrofitted later.
Choosing the wrong implementation partner — GROW with SAP requires SAP Implementation Services certified on SAP S/4HANA Public Cloud. Generic SAP ECC experience is not sufficient for a successful cloud migration.

GROW with SAP Custom Development: What You Can and Cannot Do

✅ What You CAN Do	❌ What You CANNOT Do
Extend via SAP BTP side-by-side extensions	Write Z-ABAP programs inside GROW with SAP core
Use SAP Build Apps for custom UI/Fiori apps	Create custom database tables (Z-tables) in the core
Integrate third-party apps via SAP Integration Suite APIs	Modify standard SAP source code or dictionary objects
Configure custom fields using Key User Extensibility	Use traditional enhancement spots or BADIs in core
Build custom reports via SAP Analytics Cloud or BTP	Deploy custom programs that bypass standard workflows

The Role of SAP BTP in Your Migration Strategy

SAP BTP is the backbone of the GROW with SAP custom development story. Think of it as a separate development platform that sits alongside your GROW with SAP system, connected via well-defined APIs, and hosted on the same hyperscaler infrastructure (AWS, Azure, or GCP).

For Indian enterprises, SAP BTP is available on data centres in the Asia Pacific region (Singapore, Mumbai). This means data residency concerns — which are significant for regulated industries like pharma and BFSI in India — can be addressed without compromising on cloud benefits.

Key BTP services relevant to custom development migration include:

SAP Cloud Application Programming Model (CAP): For building backend services that extend GROW with SAP with custom business logic.
SAP Build Process Automation: For workflow automation that cannot be handled by standard SAP approval workflows.
SAP Integration Suite: For connecting GROW with SAP to Indian-specific systems like GSTN, IRP for e-invoicing, MCA21, or logistics platforms like Delhivery, Ecom Express.
SAP Analytics Cloud: For custom dashboards, MIS reports, and management reporting that goes beyond standard GROW with SAP embedded analytics.

What is custom ABAP migration to SAP BTP? It is the process of taking legacy ABAP-based custom code from SAP ECC or Business One and rewriting it as cloud-native BTP extensions using CAP (Node.js/Java), SAP Build Apps, or integration flows — so the GROW with SAP core remains clean and upgrade-safe while business-specific functionality is preserved.

Cost Considerations for GROW with SAP Migration in India

SAP Migration in India

One of the most common questions we get from CFOs and IT heads at Indian manufacturing or pharma companies is: what will SAP S/4HANA Cloud migration India actually cost, especially when we have significant custom developments to handle?

The honest answer is — it depends on the volume and complexity of your custom code. Here is a rough cost framework for Indian mid-market companies:

Custom code audit and classification: ₹3–8 lakhs (one-time), depending on ERP complexity.
Fit-to-Standard workshops: ₹4–10 lakhs, typically included in the overall implementation fee.
BTP extension development per module: ₹8–25 lakhs depending on complexity (e.g., GST integration extension, dealer portal, custom MIS).
GROW with SAP licensing: Starts around ₹18,000–35,000 per user per year depending on the edition and modules.
Data migration: ₹5–15 lakhs for a standard 2–3 year historical data migration project.

The total investment for a 100-user Indian company migrating to GROW with SAP with moderate customisation typically ranges between ₹80 lakhs to ₹2.5 crores over the first two years, including implementation, BTP extensions, licensing, and hypercare. This is significantly lower than a full SAP S/4HANA on-premise deployment, which can run ₹3–8 crores for similar scale.

Why 2i Solutions Is the Right Partner for Your GROW with SAP Migration

At 2i Solutions, our SAP Implementation Services have been helping Indian businesses navigate SAP transformations for years — across manufacturing hubs in Pune and Ahmedabad, pharma clusters in Hyderabad and Baddi, and logistics companies in Mumbai and Delhi NCR. Our approach to GROW with SAP custom development is grounded in three principles:

Honest Assessment First: We audit before we propose. Our custom code discovery exercise gives you a realistic picture of migration complexity before you commit budget.
Clean Core by Design: We build every BTP extension with SAP’s clean core strategy at the centre — so your system stays upgrade-safe for years to come.
India-Specific Expertise: From GST workflows to statutory compliance and multi-state operations, we understand what Indian businesses actually need from their ERP.

Whether you are migrating from SAP ECC, SAP Business One, or a non-SAP legacy system, we have the certified expertise to make your GROW with SAP go-live smooth, efficient, and future-proof.

Frequently Asked Questions (FAQ)

Q: Can I keep my custom ABAP code when migrating to GROW with SAP?

A: No — GROW with SAP runs on SAP S/4HANA Public Cloud (Public Edition), which does not allow custom ABAP inside the core. All custom logic must be migrated to SAP BTP as clean extensions using CAP, Build Apps, or Integration Suite. Engaging experienced SAP Implementation Services ensures this transition is structured and risk-free.

Q: What is the difference between GROW with SAP and RISE with SAP?

A: GROW with SAP targets mid-market companies on a cloud-first journey using the Public Edition of S/4HANA. RISE with SAP is designed for large enterprises doing a digital transformation, often starting from SAP ECC on-premise, and supports both Public and Private Cloud editions with more customisation flexibility.

Q: How long does a GROW with SAP migration take for an Indian company?

A: For a mid-size Indian company with moderate customisation (50–200 users), a typical GROW with SAP SAP S/4HANA Cloud migration takes 6 to 12 months. Heavy custom development inventory or complex multi-entity structures can extend this to 14–18 months.

Q: Is SAP BTP available in India for data residency?

A: Yes. SAP BTP is available on data centres in the Asia Pacific region including Mumbai. Indian companies in regulated industries like pharma, BFSI, and healthcare can leverage BTP with data residency in India to meet DPDP Act and sector-specific compliance requirements.

Q: What is SAP clean core strategy in simple terms?

A: The SAP clean core strategy means keeping the SAP ERP system (GROW with SAP) free of custom code so it can be automatically updated by SAP. All customisations live outside the core — on SAP BTP — and connect to the core via standard APIs. This makes the system cheaper to maintain and always current with SAP’s latest innovations.

Conclusion

Migrating to GROW with SAP does not mean abandoning your custom developments — it means evolving them into a cleaner, more sustainable architecture. The SAP clean core strategy, combined with the power of SAP BTP, gives Indian businesses a path to preserve their unique processes while gaining the agility and upgrade-certainty of the cloud.

The key is planning. A thorough custom ABAP migration to SAP BTP strategy — grounded in a proper custom code audit, Fit-to-Standard workshops, and a realistic BTP extension roadmap — is what separates a successful GROW with SAP go-live from a costly, delayed project.

For Indian companies exploring SAP S/4HANA Cloud migration, now is the right time to start the conversation. The cloud ERP landscape is maturing rapidly, and the businesses that make the move thoughtfully today will have a significant competitive advantage tomorrow.

Ready to start your GROW with SAP journey? Connect with 2i Solutions — your trusted SAP Implementation Services partner in India — for a no-obligation custom code assessment and migration roadmap.

Handling Custom Developments During Migration to GROW with SAP