Migrating SAP B1 to AWS

by | Oct 20, 2022 | AWS Blogs

Migrating your B1 operations to the cloud can be a painful process, especially if you have little or no experience with running operations on a cloud environment.

Decisions made on the planning and architecture phase can have a critical effect on the success or failure of the migration and also on the costs of the migration.

We, at Cloudbuzz , have planned and executed successfully many B1 migration to AWS for both small and large organizations.
Based on this vast experience we have built a migration process and best practices that help making this transition a lot easier.

Here are a few key notes that will help you plan and execute your migration of B1 operations:

  • Workload Assessment:
    The most important and critical phase in the migration process is evaluating how much workload you have in your current B1 environment and how much will you need when migrating to B1 on AWS.
    If you get a clear understanding on how much compute and storage resources you need for your environment you can plan ahead and be more aware of how much will your B1 environment cost once migrated to the cloud.
    It will also help you save costs by using reservations or saving plans based on your compute assessments.SAP and AWS are providing simple sizing options for customers to predict and plan how much compute resources they will need to migrate their B1 environments to the cloud:

https://aws.amazon.com/sap/solutions/business-one/

Measure your user activity on the current on prem B1 system and use the sizing options provided above to assess the required compute power for the migration.

  • Choosing the right region to deploy
    The decision about the region to deploy on the cloud should consider the current physical location of your users and on prem network.
    To help you decide, AWS are providing a service to estimate the latency from your location to each region on AWS:
    https://speedtest.globalaccelerator.aws You can use this tool to find a region with low latency, which will help avoiding network performance issues
    Besides latency, decision about the region can affect the costs and the list of AWS features available for use.
    Large regions such as us-east-1 or eu-west-1, usually provide the latest features of AWS earlier than the smaller regions.
  • Network architecture
    SAP and non-SAP environments on Cloud can be exposed to many security risks.
    This is why we always recommend on deploying your workload on private networks with no direct access to and from the internet.

    As a best practice, we recommend on deploying separate VPCs for Prod and Non-Prod systems.
    Inside each VPC, we recommend to deploy the DB and Service layer instances in a dedicated subnet and the Client instances (Terminal servers) on another subnet.

    If you are working with AD on your on-prem network, we recommend creating an additional VPC for shared resources.
    On this VPC, create a private subnet and deploy a DC on that subnet which will sync with the on-prem DC.

    Connect your on-prem/user network to AWS using a VPN connection.
    It can be AWS site-2-site VPN, or another 3rd party VPN solution from AWS marketplace.
    If your users are spread globally and you can’t avoid enabling access from the internet to the system, use B1 Web browser and publish it to the internet using AWS Application Load balancer and AWS WAF to get better protection without allowing direct RDP access (3389).

    To secure the AWS environment even more, we recommend using a dedicated VPC for network inspection and using a central FW to manage all access, to and from the AWS environment.

    Communication between all VPCs and OnPrem should be managed by a transit GW to have more flexible management in case more networks will be added later

    One more thing regarding VPCs and Networks, Plan your VPCs and subnets with enough addresses on the CIDR to deploy all your resources.
    Create subnets for both primary and DR (On a different AZ) on each VPC in advance.

  • SAP B1 Deployment architecture
    SAP B1 comes in 2 flavors: Based on SQL Server and based SAP HANA. Both are supported on AWS.
    Regardless of your existing on-prem B1 DB platform, we recommend on SAP HANA when migrating to the cloud. SAP HANA on AWS, especially for B1, provides more scalable DB Platform and better performance.
    All HANA-supported instances on AWS have a detailed storage configuration on AWS documentation to ensure you get the maximum performance from your HANA instance.
    Besides performance, SAP HANA requires much less maintenance than SQL Server over time.On the production environment, we recommend deploying the service layer on a separate instance to avoid resource exhausting on the DB instance during high load on the service layer.
    Starting SAP B1 v10, Service layer OS resources consumption management has changed, and high load can cause higher CPU and Memory usage.
    Check SAP note 20220220 from more info.As recommended by SAP, for client access, we recommend deploying Microsoft RDS farm.
    It is easier to manage and it provides a unified work environment for all the users.
    As for addons, try to use lightweight addons to avoid high resources usage for each user session.
    If you have any addons that are not in use, it is best not to migrate them at all.
    Follow AWS recommendations regarding the size of the session hosts instances.
    If you have more than 200 concurrent users, it is better to split the users load between more than one session host.
  • Use infrastructure as code
    One of the best advantages in working with cloud environments is using code language to deploy and manage all resources in the cloud.
    SAP on B1 deployments on AWS can also be managed by IaaC solutions.
    You can choose CDK CloudFormation stacks or even Terraform to deploy your entire AWS environment in few hours.Following the deployment, every change in the environment can be also managed by IaaC.
    Working with IaaC helps organization to deploy large changes quickly, keep track on changes in the infrastructure and avoid human errors.
    New system copies for testing or training, can be deployed in few hours and with minimal effort of the IT teamsOn Cloudbuzz we use our own developed modules to automate deployment of SAP B1 environment from the network level to the HANA and B1 installation process

 

  • Backup and DR
    With SAP B1 On HANA, You can backup HANA straight to S3 Bucket using AWS Backint agent for HANA.
    S3 Is a storage service by AWS, providing low cost fast and durable object based storage perfect for backups such as HANA backups.
    On S3 you can manage the backups retention using lifecycle rules.

    For the instances, we recommend using AWS Backup service.
    With AWS Backup you can schedule snapshots for the instances and manage the retention for them.
    Besides snapshots, AWS also provides the auto host recovery feature for EC2 instances.
    With auto host recovery, AWS provides an automatic instance recovery to another hardware in case the existing hardware fails.
    This process is completely automated and supported for SAP HANA instances and it can be activated from the EC2 instance configuration.

    As for DR, AWS Elastic DR service is fully supported for SAP HANA as a DR solution.
    The deployment of AWS DRS configuration can be managed using IaaC  and can take only few hours to complete.
    DRS supports triggering a DR Drill, allowing IT teams to test the DR environment without affecting the Production environment and users.

    Using DRS does not required standby instances, all data is replicated by agents to a standby storage on the DR site and instances are started on DR using launch templates created in advance.
    Relying on the storage level, saves the total DR environment costs and provides a low RPO/RTO DR solution for your entire SAP B1 environment on AWS.

    To make the process even simpler, for the DR network you can create another VPC with Identical CIDR and subnets as the Primary VPC and manage the routes to this VPC during DR on the Transit GW level:

This way all instances will be started on the DR site with the same IP addresses and no actions will be needed after moving to the DR site.

  • Timing is everything Migration of a core business system such as SAP B1 is a major event, both for technical teams and the business users.
    Plan your migration to the cloud to avoid unnecessary downtimes for the business.
    If your SAP B1 on prem systems are running on an end of life or near end of life hardware, Start the workload assessment now and plan the migration of you B1 to the cloud.
    If you are running SAP B1 with an unsupported version of B1 or DB, Plan your upgrade to B1 10 together with the migration to the cloud.

    We, at Cloudbuzz, will be happy to assist and support you organization in the migration journey. From the Assessment and planning phase, all the way to the Go-Live on AWS

 

Roey Goldstein
Senior Solution Architect