Delivering SAP for the Cloud
In the last few years, the way SAP systems are delivered and maintained has changed more rapidly than at any point in the platform’s long history through SAP cloud platforms.
This is changing the technology, but also how people work together across organizational boundaries. Cloud migration programs are creating a new kind of working environment, one where internal SAP teams and external consultants have to collaborate far more closely, and often far more regularly, than ever before.
These changes are blurring the lines between roles that were once clearly separate.
SAP professionals within organizations are increasingly working side-by-side with outside specialists in shared teams, with shared outcomes. That brings new ways of working, but also new tensions, responsibilities, and expectations.
This article from IgniteSAP explores how cloud migrations are reshaping those relationships, and what SAP professionals, both client-side and consultancy-based, can do to succeed in this evolving ecosystem.
Redefining Roles in the Cloud Context
Until now SAP consultants were often brought in as temporary experts to deliver part of a project before handing things back to the internal team. Their value was largely defined by how efficiently they could execute predefined scopes.
Internal SAP professionals were expected to focus on system continuity, compliance, and business alignment. They operated with a longer-term view, balancing stability with incremental change.
Cloud transformation has made this division less useful. Modern SAP landscapes, particularly those delivered through programs like RISE or GROW with SAP, or those built using SAP BTP and public cloud services, require constant adjustment, regular releases, and ongoing platform monitoring.
Work that used to happen in phases is now an ongoing process. As a result, many companies are no longer looking for consultants to deliver one-off projects, but for SAP professionals who can co-deliver, collaborate, and support internal capability building.
This is redefining how expertise is distributed. External consultants are being asked to work in client-led agile teams, join internal documentation processes, and take part in long-term architecture discussions. On the other side, internal teams are being asked to move faster, adopt more flexible development methods, and take a more active role in solution design and integration: areas once considered external territory.
Planning for Mixed-Team Delivery
During the planning stages of a cloud migration, the decision to structure delivery through a combination of in-house and third-party resources needs to be deliberate. That decision affects who will own which parts of the solution, how those owners will interact, and how change will be managed after go-live.
For this reason, many companies are moving away from purely resource-driven planning and instead focusing on capability models. Rather than deciding how many consultants are needed, or which internal staff will remain on which systems, they are identifying the key capabilities required to support the transition to cloud-based SAP: architecture, integration, automation, compliance, data migration, user training, and allocating these based on who can contribute most meaningfully to each area.
This avoids both underuse of in-house talent, and over-reliance on external delivery. It also sets the stage for building working agreements between internal and external contributors.
These agreements include ways of working, common documentation standards, integration workflows, and mechanisms for handling technical and design decisions jointly. The result is not just a better migration, but a more cooperative team dynamic from the outset.
Decision-Making and Technical Ownership
As project teams become more integrated, questions about who makes decisions, and on what basis, become more important. In the traditional delivery model, internal teams would usually retain final authority over platform changes, while external teams contributed options and advice. In today’s hybrid setups, the decision-making process is more collective, and more frequent.
In cloud migrations, design choices usually need to be made during each sprint, not just during planning phases. External architects may propose new extensions or workflows using SAP BTP, and internal leads may raise concerns around integration risks or long-term cost of ownership. Neither party is fully in charge, yet both are responsible for outcomes.
To avoid disputes or delays, teams benefit from clearly defined decision models, often formalized through shared architecture boards or release councils. These groups include technical and functional leads from both inside and outside the business. Their role is to review solution options, track system impact, and guide implementation choices with an eye on both business goals and platform sustainability.
Transparency in documenting decisions is another important area. In many successful programs, cross-party teams keep an architectural decision register, detailing what was agreed, why, and what alternatives were considered. This supports accountability, but also gives future teams, including any who may have entirely internal roles, an understanding of how the system came to be as it is.
Collaborative Design and Integration in Practice
Designing integrated, cloud-based SAP systems is partly about fitting together the right tools, but also it requires connecting the people who will work on, and with, those tools.
Integration work in particular has become one of the key shared tasks between internal and external experts.
In most organizations, integration spans several systems and business units. Some of those systems may be managed by in-house teams. Others may be outsourced or newly built by consultants. That means successful integration depends on cooperation between multiple contributors across companies, across geographies, and often across time zones.
Internal teams might provide legacy documentation and testing environments. External teams might build or update iFlows in SAP Integration Suite, develop BTP-based event triggers, or design middleware logic. Without a shared understanding of naming conventions, error handling, and testing procedures, those contributions quickly become brittle or misaligned.
To reduce that risk, many teams create shared integration design templates, establish common error-handling frameworks, and hold regular interface review meetings where both internal and external contributors walk through technical changes before they’re implemented. These routines may seem mundane, but they’re what keep integrations stable and transparent over time.
Change Leadership and Team Culture
Along with effective architecture and delivery, the success of collaborative SAP cloud programs often depends on the human aspects of transformation: how people respond to new ways of working, how roles and responsibilities are communicated, and how cultural differences between internal teams and external consultants are handled.
One of the most common challenges is a mismatch in pace and priorities.
External teams are usually under pressure to move fast, meet deadlines, and deliver business-oriented outputs. Internal teams often have to balance project involvement with operational support, compliance duties, and internal reporting cycles. These competing pressures can lead to frustration or misunderstandings if not discussed openly.
What helps is creating team environments where everyone feels part of the same mission. When retrospectives include both internal and external contributors, when demo sessions are presented by blended teams, and when project milestones are celebrated together, it becomes easier to create shared ownership. In some programs, consultants have also taken on mentoring or coaching roles, helping to build internal capability over the course of delivery, not just handing over at the end.
At the same time, it’s worth being realistic. Building trust across organizational boundaries takes time. It often requires effort from leaders to model inclusive behavior: giving credit to partner teams in leadership meetings, making space for cross-company feedback, and supporting decisions that reflect a shared long-term view.
Business Ownership and Adoption Readiness
What happens on the business side of a cloud migration is just as important as the technical paradigm, especially when it comes to making sure users adopt new systems and processes effectively. Here too, the line between internal and external roles is becoming less defined.
In cloud programs, consultants are increasingly involved in system configuration as well as in shaping process changes, supporting training rollout, and even developing content for tools like SAP Enable Now. Business stakeholders are more likely to be included in sprint reviews, user testing, and backlog sessions. This makes adoption planning a joint responsibility across the entire team.
Still, adoption often fails when it’s seen as someone else’s problem. A consultant may think user training is up to the internal team. An internal team may expect the consultant to document and walk through every change. The only way around this is to treat business readiness as a joint outcome from day one. That means clarifying who will create training materials, who will deliver walkthroughs, and who will answer post-go-live questions, before those tasks are required.
Some organizations go further and build internal–external change teams, combining business analysts, consultants, super-users, and enablement specialists into one group. These teams co-author communications, run workshops, and answer end-user questions together. While it may take more coordination, the outcome is better awareness, less confusion, and a smoother cutover to new processes.
Commercial and Delivery Models That Support Collaboration
The trend toward co-delivery also brings changes to how SAP programs are funded and contracted. Consulting agreements with fixed scope, fixed duration, and rigid deliverables do not always support the flexibility required in agile, mixed teams, so companies are moving toward commercial models that reward partnership and long-term thinking.
In some cases, this means using time-based or capacity-based agreements that give both sides room to adjust priorities as backlogs evolve. In others, it means tying payment to shared business results, such as improvements in data accuracy or reductions in process time. What matters most is that contracts reflect the way teams actually work.
Commercial transparency is also an ideal to work towards. When internal and external teams have access to shared dashboards showing costs, backlog status, and delivery outcomes, it becomes easier to discuss priorities without suspicion or defensiveness. This can be especially useful in governance forums, where project sponsors need to understand both what has been delivered and how resources are being used.
These models work best when vendors are treated as part of the long-term strategy, not just project-specific suppliers. Some companies even co-invest in innovation with their partners: building BTP apps, automations, or analytics tools that serve both parties and can be reused across programs. In this context, consultants are contributors to strategic capability.
Architectural Coordination in the Cloud
In cloud-based SAP, architecture is no longer a single design exercise. With quarterly updates, extensibility options via BTP, and the increasing use of event-driven models, technical decisions have to be revisited regularly. This creates a new type of architectural rhythm and a new set of demands on both internal and external teams.
Architecture boards now meet to sign off high-level designs, and also to revisit decisions based on new product releases, cost observations, or changes in process ownership. These boards often include internal enterprise architects, partner developers, and sometimes even SAP representatives. Their purpose is to keep the environment stable without slowing innovation.
What makes this work possible is having shared tooling, documentation, and version control. Teams that maintain a joint integration registry, shared GitHub repositories, and consistent naming conventions are better positioned to adapt their IT landscapes without creating confusion. Just as importantly, they can onboard new team members faster and with fewer gaps in understanding.
Looking Ahead
As SAP moves further into cloud delivery, and as more organizations adopt a platform approach built around SAP BTP, the boundaries between internal and external delivery teams will become increasingly unclear, but as long as it is carefully managed, this is a good thing for all involved.
Project-based delivery is giving way to product-based teams. Specialists are being asked not just to execute but to coach and co-own. And success depends less on any single individual’s knowledge, and more on how well various teams work together.
This requires new contracts, new behaviors, and new expectations on all sides. But it also brings new opportunities to build smarter, more responsive, more resilient SAP landscapes that evolve continuously with the business.
SAP delivery is now a shared and ongoing process. The more SAP professionals can adapt and contribute to a model where ownership, learning, and delivery are distributed across the team, the more valuable and adaptable they will be in the years ahead.
If you are an SAP professional looking for a new role in the SAP ecosystem, our team of dedicated recruitment consultants can match you with your ideal employer and negotiate a competitive compensation package for your extremely valuable skills, so join our exclusive community at IgniteSAP.
link