Our company wants to upgrade SAP R/3 4.7 to ECC 6.

0 EHP6
As per my understanding OS 2003 and Oracle 9.2 is not supported for ECC 6.0 EHP6.
Our Current Configuration is of Oracle 9.1 and OS as windows server 2003 for R/3 4.7 but we want to upgrade it to
Oracle 11.2 and OS as windows server 2008 R2.

SAP Technical Upgrade from R/3 4.7 to ECC 6.0

Introduction

This blog covers details from Technical perspective ( for Team Leads/ Software
Engineers/Developers) for doing an upgrade from R/3 4.7 to ECC 6.0. Following are the
major points which would be covered :

1. Pre-Upgrade analysis
Study the existing landscape & the To-Be Landscape
Plan the soft freeze & Hard freeze transport strategy
Run the pre-upgrade tool to identify the no. of programs which would be reflected
for UCCHECK , Upgrade fixes etc. If you do not have an in-house tool, then you
may consider developing one. This tool would have details of Obsolete FM's,
search for CALL TRANSACTOIN statement, obsolete ABAP statements etc.
Based on such details the tool will search for all the programs which have such
FMs/Statements etc & then it will provide a list of impacted objects
Number of cloned objects ( Copy of Standard programs which are modified to
meet additional requirements)
Number of Standard Objects modified ( Core Code Modification done by
Customer in standard objects )
Number of objects which would be impacted due to updation of Unicode flag
Number of BDC programs
Based on the no. of objects reflected, you can plan the technical team
size/duration etc. This will help during project planning
The Functional consultants can go through the config. settings / level of
customization etc. This will help to identify any specific test scenarios & amount
of testing required.
Identify the number of interfaces/ 3rd party systems interacting with the SAP
system
Identify the printer/Barcode scanner etc compatibility with the new system
Basis consultant may go through the system & identify the need for additional
hardware/sizing etc.
Based on the inputs from Technical/Functional/Basis consultants you may
prepare a draft Project Plan
Prepare a landscape document ( AS IS & TO BE )
Also prepare the Technical & Funtional analysis document which can be shared
with the team
2. Project Plan/Resource planning
You may have to schedule meetings with Customer to understand there timelines
& project plan. i.e. Overlapping of any other projects, hardware availability,
Priority of any other projects etc
In consultation with Customer finalize the timelines for each phase incuding the
number of mock runs etc
Finalize the project plan & share the same with Customer
Identify the POC from both sides for each phase/task/activity
Prepare the resource plan
Start the offshore connectivity setup & onboarding of team members
You may share the landscape & other documents with the team members so that
they get acquainted with the system.

3. SPDD phase
During this phase execute the SPDD transaction. The SPDD transaction would
return All the Standard Data Dictionary objects viz Data Elements/Domains/
Structures/ Tables/ Append structures etc which have been modified by
Customer.
The technical team has to decide whether they want to RESET TO ORIGINAL or
ADOPT MODIFICATION. This two options are available to fix the objects
reflected in SPDD transaction. Here the Technical team has to do a Version
comparison of the object & analyze whether they require the custom change. If
the custom change is required in ECC 6.0, then select ADOPT MODIFICATION
else select RESET TO ORIGINAL ( i.e. you do not require the custom change
which was done in the old system. Instead you want the standard version of the
object in ECC 6.0 system ).
Ensure that you put all the objects in the correct SPDD TR
To avoid doing SPDD again in the subsequent systems, you have to release the
SPDD TR in a different way
Goto SPDD tcode & click on "Select for Transport", place the cursor on the task
of the Main TR & then release the Task. Similary place the cursor on the main
TR & then click on 'Select for Transport'. This will ensure that the SPDD fixes
done in DEV are automatically imported at OS level in the subsequent system.
Provide the TR number to the BASIS team & they would ensure to import the
SPDD TR at OS level.
SPDD activity has to be done only in 000 client. Ensure that you do not do it in
any other client.
The system would be completely open & it wont ask for access keys to modify
standard objects. So be careful while fixing SPDD objects & ensure that you do
not touch any other object which is not part of SPDD.
4. SPAU
SPAU is performed in the normal client i.e. DEV client.
Execute tcode SPAU once BASIS gives a go-ahead
You will get a list of affected programs.
The programs are standard objects which are modified by customer with some
custom changes
Analyse the changes & identify whether you need the custom changes (Adopt
modification ) or you want to go ahead without the custom changes ( Reset to
Original )
Ensure that you include all the fixes in a Transport Request - SPAU
Provide the TR number to BASIS, so that they can import the same TR in
subsequent systems
SPAU generally reflects
Programs/Includes/Screens/FM's/BADI's/Messages/Classes etc
5. UCCHECK
Execute tcode UCCHECK
This will provide a list of impacted objects. This activity would require 1 to 2
weeks depending on the number of custom objects reflected in UCCHECK
Ensure that all the fixes are included under a single UCCHECK TR
Testing of the fixed objects have to be done by developer & functional consultant
Modlogs & documentation to be maintained in the programs which are
modified/fixed
6. Custom objects remediation
Apart from UCCHECK objects you need to check custom programs which are
reflected by the upgrade tool
Fix the programs & include it either in UCCHECK TR or another TR which would
be imported after UCCHECK TR
All the custom program fixes have to be tested
Ensure that the documentation/commenting/Modlog etc is properly maintained
7. Testing
Unit testing to be done as per the Test scripts
UAT to be done as per the test scripts
If Solution Manager is used, then the tcodes have to be executed from SolMan
Results to be documented whereever applicable
PDF outputs/Print/Barcode scanning/ Background Jobs/ Workflows / Interfaces
etc has to be tested thoroughly
8. Post Upgrade activities
There are some activities which cant be included in a Transport request. Such
activities have to be manually executed in each system after upgrade. These
activities are called as Post upgrade activities. eg. Regenerating ABAP Queries
after upgrade - This cant be captured in a TR, hence has to be done in each
system
Prepare a list of Post Upgrade activities & update the details along with
Primary/Secondary Contact, Task details, System against which you can update
whether the task is completed or pending. This tracker would help to monitor the
status
Down time has this activity as well. So ensure that you have documented all the
post upgrade activity detail so that you spend less amount of time during PRD
post-upgrade activities. Try to automate whereever possible.
9. Different trackers required
Cloned program modification tracker
Custom Changes in Standard program moved to Implicit Enhancements
UCCHECK tracker
SPDD tracker
SPAU tracker
Access key request tracker
Transport tracker
Post Upgrade activities tracker
OSS message tracker
Unit Testing/UAT tracker
Test script preparation tracker
10. Common issues faced during Upgrade

Workflows
Q : Will the upgrade affect open work items
A : It is perfectly fine to have open work items when upgrading. Any open work items of
old version can be executed in the upgraded ECC 6.0 version. Ensure that all the
associated notes listed in Note 1068627 are applied in your system. [1068627 -
Composite note about workflow upgrade].

Spool SP01
Q : Is there any impact on spools created in the old version
A : Yes. All the old spools which are reflected in SP01 in the old version cant be
retrieved post upgrade + Unicode conversion to ECC 6.0. Hence the old spools which
are required post upgrade has to be either archived/converted to PDF/printed before
the upgrade. Please refer note 842767 for additional details.

Obsolete Tables
Q : Are any table made obsolete in ECC 6.0 as compared to R/3 4.7
A : Yes. Table TVARV is replaced with TVARVC & table TTXER is replaced with
TTXERN.
Table TVARV is replaced with TVARVC
Check if any entries are read from table TVARV in any of the custom programs. If yes
then all those custom programs have to be changed to read data from TVARVC. Refer
note 557314.
Execute program RSTVARVCLIENTDEPENDENT. This program transfers entries
of table TVARV to TVARVC (program doesnt have selection screen. Check the number
of entries in both the tables before & after executing the program).
Table TTXER is replaced with TTXERN
Check if any entries are read from table TTXER in any of the custom programs. If yes
then all those custom programs have to be changed to read data from TTXERN.
Execute program SDTXT1AID to copy entries from table TTXER to table TTXERN.
Check the number of entries in both the tables before & after executing the program.
Refer note 900607.

Output of program SDTXT1AID. There could be some entries which wont get
copied from TTXER to TTXERN. They either would be duplicate or incorrect entries
which you can ignore.



Program Variants
Q : Are variants affected due to upgrade.
A : Yes, variants are affected after upgrade. After Upgrade, run program RSVCHECK
which will list down all the variants which are affected. Run program RSVARDOC_610
with necessary values to adjust those variants. However if a selection screen field has
become mandatory for a tcode due to upgrade it has to be addressed by assigning a
value to it manually.

ABAP Queries
Q : After upgrade, the query dumps when we try to execute it
A : ABAP Queries are affected due to upgrade. We need to regenerate the queries post
upgrade. We can re-generate the queries using FM RSAQ_GENERATE_PROGRAM
which uses work area, query name and user group as input. If the queries are more in
number we can write a small program using above FM and table AQGQCAT- for global
query and table AQLQCAT- for local/client specific query


Q : ALV layouts previously created from SAP queries no longer function
correctly after upgrade
A : Refer note 725468

SPDD
Q : There are many objects reflected under DELETED OBJECTS node.
How do we fix this?
A : Objects reflected under DELETED OBJECTS should be ignored & need not be
fixed.

Q : How to handle the transport of SPDD as BASIS wants the SPDD TR to be
imported at OS level
A : Ensure that all the fixes wrt SPDD are captured in a single Transport. Multiple
transports are not acceptable for SPDD fixes. While releasing the task of your SPDD TR,
click on SELECT FOR TRANSPORT button which is in SPDD tcode 2nd screen.
System will prompt to confirm the TR for subsequent system. Confirm the TR number &
proceed. The SELECT FOR TRANSPORT step is extremely important else your BASIS
team wont be able to import the SPDD TR at OS level in the subsequent system.



SPAU/ fixing core code modifications
Q : Can the Enhancement framework be used to fix SPAU objects
A : Yes. SAP has introduced Enhancement framework along with ECC 6.0. For all the
core code mods reflected in SPAU, check if there exists a possibility of moving the core
code mod to an implicit enhancement. If yes, then remove the core code mod & paste it
in the new enhancement. Custom code which is inserted at the start and end of a
INCLUDE or a SUBROUTINE can be moved to implicit enhancements. This will help
during subsequent upgrades & will save an object from core code mod.



Third Party objects
Q : How to handle 3rd party SAP programs
A : Check with the 3rd party vendor for the programs of ECC 6.0 version. Normally all
the 3rd party SAP certified vendors maintain the set of programs for each version. So
once you upgrade to ECC 6.0, you need to contact your vendor & ask him to provide the
set of programs for ECC 6.0 version. Vendor would have a team which would take care
of making the 3rd party objects in your system Unicode compatible for ECC 6.0.

Obsolete Transactions
Q : Are there any obsolete transactions in ECC 6.0
A : Yes. E.g. VOTX is replaced by VOTXN in ECC 6.0. Goto table PRGN_CORR2 &
check list of old & corresponding new tcodes against your SAP Version.


Obsolete FMs
Q : How do I know if any of the custom programs are using obsolete FMs?
A : Table TFTIT would reflect obsolete FMs. Please use following steps to get the list of
obsolete FMs. You may create a small program to check all your custom programs for
usage of obsolete FMs. Such FM calls should be replaced with appropriate replacement
FM.



Usage of Internal SAP FMs in Custom programs
Q : What if my system has some custom programs using FMs which are not
released to customer?
A : As per SAP, any objects which are not released to customer can be changed by SAP at
any point of time. Such objects need not be backward compatible. The output of
programs using such FM can vary. SAP wont be taking any responsibility nor will
provide any note/solution if customer has used a non-released (internal SAP) object.
Any kind of data loss or any other impact would be sole responsibility of customer. E.g.
FM SO_OBJECT_SEND is internally released for SAP use & should not be used in any
custom programs. If its used by customer, then they need to replace the call to this FM
with another FM SO_DOCUMENT_SEND_API1. PDF files created using
SO_OBJECT_SEND cant be opened in ECC 6.0 as the FM has undergone some
changes in ECC 6.0. Hence all the custom programs which are using
SO_OBJECT_SEND should be replaced with appropriate FM.
Customers should create a tool to identify a list of custom programs where non-released
(Internal SAP ) FMs are being used. Programs which are calling such FMs should be
modified to point to suitable replacement FM.
If a FM was released to customer in old version (say 4.7) & later on was changed to
Internal SAP only, then in such case SAP would provide a note.

Post Upgrade Activities
Q : Will there be any manual activities involved post Unicode conversion
A : Yes. While doing the upgrade on Development system, you would come across few
fixes which cant be captured in a transport request. Such task has to be documented in
a Post Upgrade Activity Tracker & such activities have to be carried out in all the
subsequent system post Unicode conversion.
E.g. 1. Execute program SDTXT1AID as per note 900607
2. Execute FM "RSAQ_GENERATE_PROGRAM" for all the queries to regenerate them

Ensure that you get authorization to necessary tcodes before hand as there would be a
very small window to perform Post Upgrade activities on Production system. In order to
reduce the entire downtime, documenting the post upgrade activity tasks & providing
necessary authorization, keeping the related notes handy would definitely help.


Cloned Programs
Q : Do we need to fix cloned programs as well?
A : Well there would be some cloned programs which have few standard includes & few
Z Includes which are copy of standard includes. If these standard includes have
undergone some change / deletion / modification etc, then there is a possibility of the
cloned program giving dump/error. Hence as a preventive step, all the cloned programs
should be validated (syntax check) & tested. There is a possibility of the Main program
undergoing lot of changes due to upgrade. Customer has to take a call to decide if they
want to create a clone program of the upgraded version of std. program or would like to
continue with the old version of the cloned program.


Objects to be ignored for UCCHECK
Q : Which objects can be ignored for UCCHECK?
A : Following objects can be ignored for UCCHECK:-
All the $TMP Objects
Objects which exist in development system but not yet transported to Quality. If you fix
these objects, you might end up including it in the UCCHECK transport which would be
forwarding such type of objects to subsequent systems without testing/UAT/sign-off
from customer.
Objects under Local Workbench TR
Inactive Objects/Objects having error in old system (E.g. A custom program which is
having error in R/3 4.7 system need not be fixed in ECC 6.0 for UCCHECK)


Checkbox declaration to be changed
Q : Do we need to change parameter declaration of TYPE CHECKBOX
A : Yes. In SAP 4.6c version TYPE CHECKBOX used to create a checkbox on the left
hand side with the corresponding text on the right hand side. But after upgrade the
same code is creating Checkbox on the right hand side with the text on the L.H.S.
Few users prefer to have the same selection screen, the way it was in the earlier version.
Hence modify the custom programs to replace TYPE CHECKBOX with AS
CHECKBOX.
You may identify all the programs using TYPE CHECKBOX with the help of search
string program RPR_ABAP_SOURCE_SCAN.


EDIFCT custom table entries
Q : While upgrading to ECC 6.0, custom entries in table EDIFCT are deleted
A : Yes, the upgrade deletes the custom entries from EDIFCT table. Before upgrade take
a backup of EDIFCT table entries as per note 865142


Replacing WS_DOWNLOAD FM
Q : WS_DOWNLOAD FM should be replaced with GUI_DOWNLOAD FM?
A : Yes, the new replacement is FM GUI_DOWNLOAD. While replacing check if the
MODE parameter is passed with value A in the program. If yes then you need to
ensure that for FM GUI_DOWNLOAD APPEND parameter is set to X.
Similarly check if the FIELDNAMES is assigned to any internal table. If yes, then in
GUI_DOWNLOAD pass the same internal table to FIELDNAMES.


This is a huge project and not straight off reading documentation will help. You need
experienced consulting and SAP guidance to do this migration especially depending on
the
complexity (modules implemented, custom programs and custom tables, etc.) of your
system.

As Dammah says, this is huge. As things stand right now, SAP will allow you to do the
technical migration in-house, but the data migration from Classic to New GL must be
handled by them or an approved SAP partner. They won't let you handle that bit in-
house, as it's very tricky with room for disaster. You need to approach SAP as soon as
you can so they can help you define the project plan and time line.

Hi, Ramakrishnan - There is mention here of New G/L, but is your client requiring a
move to new G/L? Is this just a technical upgrade (make what works in 4.7 work in 6.0)
or is there a functional upgrade going on as well? You can go to 6.0 without configuring
new G/L.

Testing is always the largest job. For a technical upgrade, in my opinion, the entire
project is more about testing plans than anything else. Use SAP information about what
transactions and processes are used in the FICO area - Basis can help with usage
statistics. Then design the test plan to ensure that everything that worked in 4.7 is still
functioning in 6.0. Fix and retest accordingly.

If this is to be a full functional upgrade as well, then there is no cookbook to tell you
what to do. Based on the requirements for the new functionality, everything will need to
be tested, but you have no road map for the new functions and you don't know what the
new functionality will do to existing processes that worked before and may not work
now. The testing is much more complex, and I would recommend working with a
consulting team that has done functional upgrades.

As is always the case, the more customized the system is, the more the possibility of
something not working in the next release. There are tools available from different
vendors that will look at a system and make some pretty good predictions about what
will work in the next release and what won't. You can make use of what those products
tell you to fashion your testing plans.

Good luck!
SAP Upgrade
8/3/2007 by ITtoolbox Popular Q&A Team for Toolbox for IT as adapted from SAP-
PROJECTMANAGEMENT discussion group
Summary:
I am about to start in a new job as the general manager for a small/midsize company in
the seafood manufacturing business. They have implemented SAP five years ago, and
it was now mentioned that an upgrade was necessary quite quickly. I have experience
from ERP implementation, but never worked with SAP, or with an ERP upgrade. Can
anyone give me some advise what to be aware of in terms of deciding when to do the
upgrade and for the process of doing it?
Full Article:

Disclaimer: Contents are not reviewed for correctness and are not endorsed or
recommended by ITtoolbox or any vendor. Popular Q&A contents include summarized
information from SAP-ProjectManagement discussion unless otherwise noted.


1. Adapted from a response by syednaqi.hyder on 5/31/2007
We are about to start the Upgrade of SAP R/3 4.6c to mySAP ERP ECC 6.0 for one of
our clients. Since you are new to SAP, I suggest you to identify a good SAP Partner in
your area. The partner would provide you all necessary advice and the approach to be
adopted for upgrading your current version to mySAP ERP ECC 6.0.


2. Adapted from a response by syednaqi.hyder on 5/31/2007
Here is a typical upgrade project plan so you can have an idea as to what all happens in
an upgrade project. These are very typical steps, but they may differ in your case due to
the Hardware/OS/Database that you are currently using. Please do not assume that all
upgrade projects can happen in this time itself. A SAP partner has to understand your
current systems and suggest the approach and timelines.

*Preparation Phase* *6 days*
Kick Off Meeting 1 day
Upgrade Project Procedures Preparation 1 day
Prepare Upgrade Project Plan 1 day
Technical Requirements Assessment 3 days
Assess Training needs of Key-users & End-users 1 day
Prepare Detailed Basis Activity List for DEV, QA & PRD 1 day

*Business Blueprint Phase* *6 days*
Develop System Landscape Upgrade Plan 1 day
Functional Requirement Checklist 1 day
ABAP Development check list 1 day
Develop detailed Training Procedures & Documentation for Key Users & End Users 1
day
Identify Testing Scope & Scenarios 1 day
Identify Authorizations Conversion to Roles for SAP ECC 6.0 2 days
Develop Documents as per Basis Activity List 1 day
Develop Authorization Matrix for Activity Groups to Roles Conversion 2 days
Prepare Upgrade Deliverables Checklist 1 day

*Realization Phase* *28 days*
Installation of Solution Manager 3.2 System 1 day
Creation of New Development System for Upgrade Project (Homogenous System Copy
- PRD) 2 days
Upgrade to AIX & Oracle 10g, SAP ECC 6.0 on New Development Server 3 days
Upgrade Frontend Software 4 days
Perform SPAU & SPDD Corrections 5 days
Perform ABAP Development & Corrections 10 days Perform Authorizations
Conversions and corrections after upgrade 8 days
Perform Upgrade Testing for each Application Module 7 days
Perform Unit & Integration Testing 6 days
Perform Training to Key Users & End Users (Generic & Specific) 3 days
Upgrade to AIX, Oracle 10g, SAP ECC 6.0 on Quality System 1 day
Homogenous System Copy of PRD to New Quality & Upgrade to AIX, Oracle 10g &
SAP ECC 6.0 2 days Perform Testing in Quality System 3 days
Testing by end users on Quality System 1 day

*Production Realization & Go-Live Phase* *6 days*
Upgrade to Production System Operating System to AIX (after close of business hours -
23:00) 1 day
Oracle Upgrade to 10g (after close of business hours - 23:00) 1 day
SAP Release Upgrade to ECC 6.0(Downtime Minimized - Downtime occurs in non-
business hours) 2 days
User Acceptance Testing 1 day
Production System Go-Live 1 day

*Post Go-Live Support* *14 days*
Post Go-Live Support 14 days Note: This is high level plan subject to change during
Business Blue Print Phase 0 days


3. Adapted from a response by snista on 5/31/2007
There is a good deal of information to be considered before undertaking an SAP
upgrade, particularly if the company is moving from an older version of SAP to the latest
where there are significant technology differences and could be some infrastructure
changes. Also, you need to determine if they
Disclaimer: Contents are not reviewed for correctness and are not endorsed or recommended by Toolbox.com or any
vendor.
Popular Q&A contents include summarized information from SAP Project Management
discussion unless otherwise noted.
How to Upgrade from SAP R/3 to SAP ERP 6.0
August 13, 2010
SAP News
David Velez
Thinking of upgrading your SAP software and transferring your data as you move to new hardware? In our new article series, well show you
the basics of carrying out an SAP ERP upgrade, right up to the point of going live. For an overview, simply continue reading part one.

There really are two completely different worlds: While private users update the software on their computers nearly every year, companies
run the same programs on their servers for 10 to 15 years. After all, corporate clients have neither the option nor the desire to switch
IT systems on a whim. Meeting the short-notice requirements of todays interconnected economy, however, does sometimes demand
fundamental changes in companies ERP systems. This, in turn, entails the latest version of the software in question; see our article
Preview: EHP 5 for SAP ERP 6.0.
It starts with the question of whether the targeted software upgrade will require a new hardware platform. Many companies run dated server
hardware that should be swapped out during the transition to the latest generation of SAP software. We cover this later in the series based
on the example of an actual company that switched SAP systems in 28 hours. Without sound preparation prior to the upgrade itself and strict
adherence to the prescribed sequence of actions, this would not have been possible.
This initial installment of our article series delivers an overview of the entire upgrade process without delving into the details. We then
describe the updates legacy systems require; the installation of new servers, including operating systems and databases; the installation of
SAP R/3, along with backups of the previous data status; database upgrades, and finally, the actual transition to SAP ERP 6.0, including
installation of the latest enhancement package (see also EHP: Keeping SAP Up-to-Date ).
As has been especially apparent at industry events and special in-house exhibitions, larger companies in particular have recently been
considering bolstering their ERP systems. The basic tenor being heard from many IT managers indicates that numerous companies still rely
on SAP R/3 4.7200 and the key components FI, CO, FM, SD, MM, and HR. Over the years, these organizations have expanded their live
systems and made other constant adjustments to meet current predominant requirements. It should be noted, however, that while
maintenance is still offered for all SAP R/3 systems, updates are no longer released for the software.
Those interested have the option of making an incremental transition from SAP R/3 4.7c to SAP ECC6.0 (ERP Central Component), the
latest version of the application. In this series of articles, well tell you which basic steps are necessary to upgrade while aiding your general
understanding of the process with plenty of screenshots. Meanwhile, the different sections will point you toward the impressive array of
documents and guides SAP offers.

ERP-Upgrade: Approach

In the following step-by-step guides, we show you how to switch from your old hardware and software to an all-new system while transferring
your data to an up-to-date database.
For the sake of our example, the starting system will be an HP ProLiant DL380 server running on four processors and the Windows 2003
Server SE operating system. Its other software components include a Microsoft SQL Server 2000 database, the 32-bit SAP Kernel 6.40
NUC, SAP ABA/BASIS 6.20 SP64, SAP APPL 4.7 SP30, SAP HR 4.7 SP84, and SAP EA-XX 200 SP15.
In the existing system, the collation *BIN is first changed to *BIN2. This is necessary to facilitate the later transition from Microsoft SQL
Server 2000 to SQL Server 2005. Each collation contains rules for sorting and comparing the entries in the Microsoft database. A full backup
is then made for the subsequent homogeneous system copy (HSC) of the SQL database.

In this case, the target system is a 64-bit Dell RAC 5 server. The system is first configured at the operating-system level; well use Windows
2003 EE x64. The database will be in the 64-bit Unicode version of Microsoft SQL Server 2005 and collation *BIN2. Well now install the 64-
bit variant of SAP Kernel 6.40 NUC. All of the necessary SAP components and their service packs will be installed on the new server as they
were on the previous configuration; this will involve a fresh installation of SAP R/3 4.7200.
Then comes the HSC, in which well restore the database backup from the previous server. The STM download takes place on SAP
Service Marketplace (direct link).
Following the successful configuration of the new system, including the operating system and upgrade from a 32-bit to a 64-bit database, we
can begin with the actual transition to the latest version of SAP ERP. Here, good planning and key-user testing that covers all of the business
processes and preceding activities involved are especially important; well deal with the latter topic in a separate article. At the end of the
overall upgrade process, well have a new SAP ERP 6.0 platform that includes enhancement package 4 . Were now ready to go live!
The image on the first page of this article summarizes our basic approach, but in practice, a number of additional steps are needed between
these phases. The only way to document them is with a great many screenshots, which we will present in the course of this extensive article
series.


Why to Upgrade to ECC6.0
Planning ERP installations and their further components for the next decade used to be something of a tradition in companies IT
departments. Major changes were a rarity, and when they were made, their scope was often still rather small. However, comparatively old
and inflexible ERP systems can no longer keep pace with todays business world. This is why IT managers are weighing the costs and
benefits of upgrading their SAP software; for more, check out Enhancement Packages Deliver the Innovations.
In the end, its mainly about reducing maintenance costs and enhancing the business processes the new SAP ERP system covers. The latter
is particularly key in coping with the increasing complexity of said processes: Obsolete software does not facilitate frequent adjustments and
changes, and even slight modifications are relatively expensive. Enter the free updates that have been regularly available since the
introduction of SAPs enhancement packages, all of which are currently included in EHP4 (see also From ERP 6.0 to Business Suite 7
and SAP ERP 6.0 at a Fixed Price).
Example case demonstrated at ITU in Geneva
We were recently on-location at the International Telecommunication Union in Geneva, Switzerland, to demonstrate our approach to
switching from SAP R/3 to SAP ERP 6.0. Founded in May of 1865, the ITU is one of the oldest international organizations and a special
entity of the United Nations. It currently comprises 191 member nations and deals with global issues concerning the technical aspects of
telecommunication.
In the days ahead, well be publishing further articles in this series to give interested readers a solid basis for upgrading their SAP software.
via SAP.info
Difference between ECC 6.0 vs 4.7EE - SAP FI / SD /
MM / ABAP (Functional & Technical)
Labels: SAP FI, SAP FI-New GL, SAP FICO, SAP HELP, SAP MM, SAP SD
ECC means Enterprise Central component.

SAP R/3 4.7 is based on the 3-tier architecture. SAP is continuously upgrading the software, which is
called as release versions for example SAP R/3 4.6C, SAP 4.7....

Now SAP evolved into using the Internet technology and is called as service oriented architecture
(SOA). There are lots of functionalities available in ECC 5.0 and ECC 6.0 compared to R/3 in integrating
with other systems. Probably to understand the specific release dependent changes, you can go thro
the help documentation. For example to understand the diff between ECC 6.0 and ECC 5.0 please go
thro the link:

Release Notes for SAP ERP Central Component (English) Click here

Some of the differences in SD Module are:

1. Document Flow

In ECC 6.0, the flow of sales documents is seen much better and improved as compared to 4.6C. Once
you look at the screen, you will clearly figure out the difference.

2. Sales Order Look and Feel

There are more tabs in ECC 6.0 for Item Level Details.
The Sales Doc. appears as supremely perfect.

3. ECC 6.0 is built on Net Weaver Technology (that possess SOA i.e. service oriented architecture),
Hence more reliable and improved as compared to previous one.


Release Notes for SAP ERP Central Component (English) Click here

Some of the differences ABAP Module side:

1. For installing ECC 6.0 you required a solution manager key. With out solution manager key you
cannot install ECC6.0.
2. ECC 6.0 is called net weaver component here you have ABAP+JAVA stack & for installing 4.6
you don't require solution manager key. It only having ABAP stack.
3. ECC6.0 supports UNCODE & 4.6C supports NONUNICODE.
4. Major difference is ECC6 is net weaver product having WASJAVA+ABAP - secondly support
Unicode apart from this we have other diff. you can get from master guide from
service.sap.com/instguides.
5. In terms of ABAP some function modules are obsolete in 4.7. e.g. WS_UPLOAD, WS_DOWNLOAD
etc. You can find the list of obsolete FMs in the table RODIR. These need to be replaced in the
ECC System.
6. Also ECC is very strict in case of EPC Errors. You need to check the EPC and remove the call
function interface errors where it says SLIN observes catching of a runtime error. These might
work with no issues in 4.7 but will short dump in ECC.
7. If you are doing to a Unicode conversion also. You need to check the transaction UCCHECK for
Unicode errors. You also need to replace obsolete statements like >< and => , =< etc.
8. If you want to know more ABAP changes go to transaction ABAPDOCU and there is a node ABAP
Changes by Release. You can see more ABAP Changes version by version here.
9. ECC is more towards OOPS concepts, ECC is very developer friendly
10. It has new debugger.
11. New Enhancement Framework is introduced in ECC.
12. It is more efficient to use Adobe forms in ECC.
13. 5.0 ECC - Build in Net Weaver Platform & 6.0 ECC - Build in Net Weaver Platform with Solution
Manager
14. ECC has new options in BADIs where you can create your own badis and implement it.
15. You have new concept called Implicit and explicit source code plugins in ECC.
16. Has webdynrpo component accessible from SE80 transaction Itself.

Some of the differences FI Module side:


1. ECC 6.0 enables Business area posting - Segment reporting made easy.
2. Profit center accounting is through new GL.
3. Document splitting: Split of entry to post assets and liabilities to respective profit centers.
(Balance sheet items)
4. Enables commitment of FM, improved CRM feature & Mobile sales feature

Here are the list of Transactions not their in ECC 6.0

QAS1 Download Insp. Specs. (Obsolete)
QAS2 Download Basic Data (Obsolete)
QAS3 Upload Results (Obsolete)
QAS4 Upload UD (Obsolete)

WLF1K Report used to generate WLF1K is: SAPLWLF1
O07C Report used to generate O07C is: SSFPSEMAINT


Check the below links to download the PDF files for the release notes of MM Module:

ECC 5.0 - MM Module Release notes

SAP R/3 MM Module Release notes

Some of the differences Basis/Technical Module side:

If you're "Basis/Technical", focusing on the underlying technical "Basis" or "NetWeaver" versions will
help you stay on the right track. Technically, ECC 6.0 is 2 "technology" versions higher. Following is the
terminology/version information for the last 3 ERP product versions:

SAP R/3 Enterprise (4.7x)
SAP BASIS 6.20

SAP ERP 2004
SAP NetWeaver 2004 (BASIS 6.40)
ECC 5.0

SAP ERP 2005
SAP NetWeaver 2004s (BASIS 7.00)
ECC 6.0

The main technology feature delivered with NetWeaver is the integrated J2EE engine (Web Application
Server Java).