Dave Essex: migrating to the cloud is a necessity for digital
transformation for SAP users. Another critical migration
involves s for HANA saps newest enterprise resource planning or
ERP platform, customers are facing a 2027 deadline to
migrate s for HANA from its predecessor, SAP Business suite,
and its digital core, ERP central component or ecc. But
the vendors looming cut off date isn't the only reason to make
the move to S for HANA. Surveys show that most SAP customers see
tangible benefits and are actively considering or planning
an S for HANA migration. Here we're going to talk about the
basics of S for HANA, and what you need to know before
migrating for a deeper dive. Explore our complete collection
on all things SAP S for HANA by clicking the link above or in
the description below. Let's first define ERP ERP digitizes
business functions like accounting, HR and inventory
management, integrates them in a single system, and records
transactions in a central database. The problem is, many
companies have old user unfriendly ERP systems that are
hard to maintain. S for HANA is designed to make ERP faster and
easier to use through a simplified data model, lean
architecture and modern user experience built on the tile
based SAP Fiori UX, the underlying SAP HANA in memory
database, speeds up queries and analytics, making it possible to
analyze large pools of internal and external data in real time,
several advanced technologies are included or integrated with
us for HANA such as AI, machine learning, Internet of Things and
advanced analytics. Companies typically move to S for HANA
because their legacy ERP systems are no longer sustainable, or
they want a more current system with access to leading edge
technologies. So say SAP implementation partners
Deloitte, ey and IBM. The potential benefits include
easier to update business models, streamlined integration
of corporate acquisitions, a simpler user interface, real
time analytics on consolidated data, more accurate forecasting,
speedier financial closes, access to the latest
technologies and lower ownership costs. And while s for HANA can
play a critical role in your digital transformation,
migration comes with a major commitment of time and resources
as well as significant risk. challenges include securing sea
level support for the migration, transitioning from legacy
environments, matching ERP functions to business needs,
dealing with a high degree of customization, working with
unclean master data, and integrating data and
applications into the new system. Businesses moving their
ERP to S for HANA have three main options that vary according
to how much gets migrated. Whether SAP or an implementation
partner provides the consulting services and whose cloud
infrastructure hosts the ERP. The three approaches to
migration are Greenfield, starting with s for HANA
finance, and using rise with SAP. A Greenfield deployment
represents a fresh start a completely new ERP system, often
running on cloud infrastructure or a new data center. It could
be a company's very first venture into ERP. But most often
a greenfield s for HANA deployment involves shutting
down another vendors ERP or an older SAP system. Transferring
existing business processes and data from the old ERP system
takes a lot of work. But this kind of wholesale move is the
best way to secure all of S for HANA has benefits including
predictive analytics, AI, Process automation and real time
reporting. A very common approach is to start with the S
for HANA finance module, while delaying the move to other
modules. This brownfield approach to migration is
feasible because accounting is a classic back end process that
doesn't change very much rise with SAP build as business
transformation as a service is a bundle of products and services
SAP offers to get customers up and running quickly on S for
HANA Cloud, and its broader ecosystem. The ERP runs on saps
public cloud or that of a hyper scalar like Amazon Web Services
or Microsoft Azure. SAP and his consulting partners each offer
rigorous strategy and planning processes to determine which
migration method is best. This part of the process is often
called phase zero. It consists of three key steps. First,
evaluate the current system, and this step also called discovery
or readiness assessment. You assess the existing ERP system,
its data and the business processes they impact. Licensing
and maintenance costs are also considered. users share their
pain points, and it takes an inventory of custom code and
analyzes master data. Second, review the architecture.
Determine how your existing ERP modules and business processes
mapped to the available s for HANA modules, and deployment
options and decide which ones to leave behind. And third, analyze
the future state. envision what the new ERP should do based on
requirements gathered from users. Department has executives
and other stakeholders try to quantify the benefits such as
cost savings from consolidating ERP systems, or launching a new
e commerce business. All this information is useful in making
the business case for ERP. There are two main versions of the s
for HANA software code, the on premises version, and S for HANA
Cloud public edition. Bear with me, the names get confusing. The
on premises version of S for HANA, which can also run into
private cloud, when it's called S for HANA Cloud private edition
doesn't yet cover all the major functional areas in business
suite. But important modules have been added to S for HANA
since the initial rollout of finance, including sales and
distribution, production planning, sourcing and
procurement and supply chain management. The divergence
between on premises business suite and on premises s for HANA
can be mission critical for many businesses. Often the decision
centers on whether to exchange existing customizations for the
standardized processes, best practices, real time analytics
and leading edge technology that s for HANA offers. The
differences between legacy SAP ERP and S for HANA Cloud public
edition, are usually even more pronounced. S for HANA Cloud
public edition is multi tenant Software as a Service, which
means it's a significantly streamlined, somewhat generic
and mostly non customisable version of S for HANA.
Understanding what public edition does and doesn't do is
critical, the size of the company, the complexity of its
operations. Whether those operations are global, and the
specific industry all should weigh heavily in the decision to
buy the public edition of s Vahana. Cloud. There is no
single pathway to a successful as for HANA migration, but these
steps are highly recommended by experts create a well devised
roadmap, take the time to align on scope, future technical
landscape and deployment. Anticipate what you might need
from S for HANA over time, so you don't get locked into an
inflexible model that requires over engineered customized
systems don't get stuck in the past. Avoid recreating the old
ERP. Don't hang on to technical debt, like the neglected
infrastructure Training and Documentation that older ERP
systems tend to accumulate. Focus on using the capabilities
of next generation ERP and is preconfigured. Industry
applications, accelerators and automated processes, practice
good governance, develop a governance model to specify
where software extensions are best suited, not just an S for
HANA. But in other parts of your SAP ecosystem. S for HANA gets
much of its mojo from an ecosystem that includes the
cloud, analytics, API, and integration tools and platforms.
The result is a more flexible technology stack that won't
overburden and prematurely age s for HANA as a development
platform and set a time limit. SAP and his partners offer pre
built templates to get some parts of the business running on
S for HANA in just six months. Sending a one year timeframe
requires a strong change management process that includes
hands on experience, so users can see how the software really
works. Many implementation partners have long histories of
sap that predate s for HANA by decades. Choosing the best
partner for your business requires due diligence. Here are
some tips. Look for a strong selection of deployment
methodologies, automated testing and data migration tools. Ask
how many people will be assigned to the project and who will be
working exclusively for you. Check for SAP S for HANA
certification, which is an indicator not only of
educational background, but also experience with s for HANA
deployment. Talk with references who have undertaken similar
projects, ideally in the same industry. Ask what kind of
support is available after the new system goes live and at what
cost? And finally, insist on written guarantees that the
project will be completed on time and stay within budget.
S for HANA migration can be a long arduous but highly
rewarding process, close collaboration among your
internal project team SAP and his partner. Plus working from a
detailed roadmap can go a long way toward ensuring a successful
s for HANA deployment.