Your SAP System is Still Non-Unicode? Here is What That Means
Covers the non-Unicode to Unicode conversion challenge for SAP systems migrating to AWS, including why Unicode is mandatory for S/4HANA, the technical conversion process, ABAP code remediation, and how to combine conversion with AWS migration.
Let me be direct - if you are planning to migrate your SAP landscape to AWS and your system is still running on non-Unicode, you have a problem that needs addressing before anything else moves forward. This is not a minor checkbox item. It is a blocker that can derail timelines, inflate budgets, and cause data integrity issues if handled poorly.
I have seen this come up repeatedly in customer engagements, and the question is always the same: "Can we just lift-and-shift our non-Unicode system to AWS and deal with the conversion later?" The short answer is - technically yes, but strategically, it depends. Let me explain.
What Does Non-Unicode Mean in SAP Context?
Every SAP system stores text data using a character encoding scheme. Older SAP systems (typically NetWeaver 7.0 through 7.4 era) were often installed with single-byte character encodings - think Latin-1 or similar code pages. This worked fine when your business operated in one language and one region.
Unicode, on the other hand, uses multi-byte encoding (UTF-16 in SAP's case) that can represent virtually every character from every language on the planet. When SAP made Unicode mandatory for all new installations starting with S/4HANA, they were not being difficult - they were acknowledging that global businesses need global character support.
Here is the critical point: SAP S/4HANA only runs on Unicode. There is no non-Unicode option. So if your end goal is S/4HANA (and it should be, given ECC maintenance deadlines), Unicode conversion is not optional - it is mandatory.
And the clock is ticking. As per SAP Note 1648480, mainstream maintenance support for SAP ERP 6.0 (ECC) is scheduled to end on December 31, 2027. The latest SAP releases - SAP ERP 6.0 EHP8 and SAP S/4HANA - are only available in Unicode, making it a prerequisite for the source system to be Unicode-compatible before upgrading. Additionally, per SAP Note 2033243, non-Unicode SAP systems must be converted to Unicode before migrating to S/4HANA.
For customers running SAP on Oracle databases and migrating to AWS specifically, SAP Note 2358420 adds another requirement - Unicode conversion is mandatory for supportability on AWS with Oracle.
Can You Lift-and-Shift a Non-Unicode System to AWS?
Yes. If you are doing a straight infrastructure migration - taking your existing SAP ECC system as-is from on-premise to EC2 instances on AWS - a non-Unicode system is supported from the AWS infrastructure perspective. The conditions are:
- The OS and database combination must be on the AWS-supported list
- The SAP system must still be within SAP mainstream or extended maintenance scope
- You are not changing the SAP version or database during the migration
AWS does not care whether your SAP system is Unicode or non-Unicode at the infrastructure layer. EC2 instances will run your workload either way. The SAP-certified instances (whether you are on r5, x1, x2idn, or the latest U7i family) support both.
But here is what AWS and SAP both recommend: Convert to Unicode either before or as part of your migration. Doing it after creates a second project, a second downtime window, and a second round of testing.
Why You Should Not Kick This Can Down the Road
According to the AWS for SAP blog post "Optimizing Unicode Conversion Downtime for SAP Systems on Oracle to AWS", converting SAP systems to Unicode involves managing multiple technical challenges: data conversion, code remediation, planned downtime, testing and validation, performance impact, and interface adjustments. Large SAP databases (10 TB+) require 1-3 days of downtime for Unicode conversion using the standard approach.
- Double Downtime - A lift-and-shift migration to AWS already requires a cutover window. Unicode conversion requires its own downtime. If you do them separately, your business takes two hits instead of one.
- Data Growth - Unicode doubles the storage requirement for character fields. Your database will grow typically 30-50% larger after conversion. If you migrate first and convert later, you are paying for that extra storage on AWS for the entire interim period.
- Testing Overhead - Every business-critical transaction needs regression testing after Unicode conversion. Custom ABAP code all needs review because string operations behave differently in Unicode. Doing this testing twice is wasteful.
- S/4HANA Readiness - Doing Unicode conversion now as part of the AWS migration sets you up cleanly for the next hop to S/4HANA.
The Technical Reality of Unicode Conversion
Database Export and Import (UCMIGRA / SUM Tool)
SAP provides the Software Update Manager (SUM) with the Unicode Migration (UCMIGRA) option. The default conversion method is to export the entire database using R3Load, create a new Unicode database, and then import the database using R3Load again.
- Export - All tables are exported from the source non-Unicode database
- Convert - Character data is converted from the source code page to UTF-16
- Import - Data is imported into a new Unicode-enabled database
This is not an in-place conversion. It is a full export-import cycle. For large databases (multi-TB), this can take days.
Important note: Starting from SAP_BASIS 750, only Unicode is possible. The conversion must happen first on the lower release before upgrading.
ABAP Code Remediation
In a non-Unicode system, you could get away with sloppy string handling in ABAP:
- Hardcoded character lengths that assumed single-byte
- TRANSLATE statements with literal character mappings
- Direct byte-level manipulation of strings
- Mixed usage of CHAR and BYTE type fields
All of this breaks in Unicode. SAP provides the Unicode Check tool (transaction UCCHECK) that scans your custom code and flags issues. Customers with 5,000+ Z-programs typically find 15-25% of them need modification. SAP Note 2602070 provides a comprehensive troubleshooting guide for Unicode Conversion and I18N issues.
Combined Approach: Migration + Conversion
The recommended workflow:
- Set up target SAP system on AWS (EC2 instances, EBS storage) - already Unicode-enabled
- Use SUM/UCMIGRA to export from on-premise non-Unicode source
- Import into the AWS-hosted Unicode target
- Run UCCHECK and remediate custom code
- Perform regression testing on AWS
- Cutover (single downtime window)
Real-World Reference: Bell Canada (11 TB in Under 5 Hours)
Bell Canada migrated their 11 TB non-Unicode SAP ERP system running on Oracle to AWS and completed the Unicode conversion in under 5 hours of technical downtime. They achieved this by using advanced Oracle database features, parallel processing, and AWS infrastructure scalability. Full case study: https://aws.amazon.com/blogs/awsforsap/optimizing-unicode-conversion-downtime-for-sap-systems-on-oracle-to-aws/
AWS Services That Help
The SAP on AWS Migration Methodology (https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-migration/welcome.html) outlines a four-phase approach (assess, mobilize, migrate, optimize):
- AWS Launch Wizard for SAP - Automates provisioning of your target SAP infrastructure on AWS.
- Amazon EBS (io2 Block Express) - During the export-import phase, I/O is the bottleneck. io2 Block Express delivers up to 256,000 IOPS with sub-millisecond latency.
- Amazon S3 - Use S3 as staging for the export files.
- AWS Backint Agent for SAP HANA - Set up Backint for HANA backups directly to S3 from day one.
- Amazon CloudWatch Application Insights for SAP - Monitor the system post-conversion with pre-built SAP HANA dashboards.
- AWS Direct Connect - For the data transfer phase, dedicated private connections reduce transfer time for multi-TB export files.
Sizing Considerations Post-Conversion
Per the SAP HANA Sizing Guide on AWS (https://docs.aws.amazon.com/sap/latest/sap-hana/migrating-hana-sizing.html):
- 30-50% growth on character data
- Larger DB means larger HANA memory requirement
- Plan accordingly - may need to go up one instance size
AWS offers SAP-certified instances from 512 GB up to 32 TB (U7i). When you have determined the base memory requirement, choose the smallest SAP-certified EC2 instance that provides more memory than your base requirement.
What If You Absolutely Cannot Convert Right Now?
A phased approach works:
Phase 1: Lift-and-shift the non-Unicode system to AWS as-is. Get off on-premise hardware.
Phase 2: Within 6-12 months, execute the Unicode conversion on AWS itself (source and target both on EC2).
Phase 3: Once Unicode is complete, you are positioned for S/4HANA migration.
Just make sure Phase 2 is actually on the roadmap with committed dates - not a "someday" item.
Final Thoughts
Non-Unicode to Unicode conversion is not glamorous. But it is foundational. Every year you delay, your custom code grows, your data grows, and the conversion effort grows with it.
If you are moving SAP to AWS - address Unicode early. Combine it with the migration if you can. Budget for the 30-50% database growth. Scan your custom code with UCCHECK now, even if the conversion is months away.
Your future self (and your project manager) will thank you.
References
- Optimizing Unicode Conversion Downtime for SAP Systems on Oracle to AWS: https://aws.amazon.com/blogs/awsforsap/optimizing-unicode-conversion-downtime-for-sap-systems-on-oracle-to-aws/
- SAP on AWS Migration Methodology: https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-sap-migration/welcome.html
- SAP HANA Sizing on AWS: https://docs.aws.amazon.com/sap/latest/sap-hana/migrating-hana-sizing.html
- SAP HANA Certified EC2 Instances: https://docs.aws.amazon.com/sap/latest/general/sap-hana-aws-ec2.html
- SAP Note 1648480 - Maintenance for SAP Business Suite 7
- SAP Note 2033243 - Unicode prerequisite for S/4HANA
- SAP Note 2358420 - Oracle on AWS supportability requirements
- SAP Note 2602070 - Unicode Conversion troubleshooting guide
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article