Short intro
HANA has been on the market for some time and can be used by SAP Business One customers in their new deployments. Those with SQL Server as a database have already started migrating their systems to SAP's new flagship platform.
This quick guide can help you take into account the myriad of considerations to resolve in order to achieve a successful project.
The migration project
Successfully carrying out a migration project from SAP Business One SQL Server to SAP Business One HANA is a task that seems trivial to start with, but has a lot of activities to contemplate and that are sometimes overestimated or taken into account.
It may be lack of experience or lack of a clear framework of steps to follow, always based on a good definition of the scope of the project and a support of technical knowledge that allows us to carry out these tasks.
When a customer wants to migrate their SQL Server system to HANA it is generally supported by an architecture like this:
To get an idea of the solution, the following image represents what we should configure in order to migrate that system to HANA according to the official product architecture:
Without going into many technical explanations, since it is not the object of this post, here the important thing is the 2 servers represented in the figure both below and on the right.
The server below represents the Linux SUSE server where HANA will operate and the one on the right is the Windows server for services and the Integration Framework + Others.
Here the important thing is that the client is clear that both environments of SAP Business One SQL Server and SAP Business One HANA must coexist in the same business network (for a specified period of time), until the migration project is successfully completed. and the technical and functional tests that correspond to apply.
Sizing
Before going directly to what would become the general project plan of a migration project of this nature, it is important that the client starts with the Partner that accompanies him to carry out the necessary estimates of resources that he will need to provision the resources so that you can install HANA.
A sample of this sizing might look something like this (take it as an example only, every customer is totally different):
In this case, what the tool suggests is the box marked in red, it is the amount of memory that HANA will use to deploy the SAP Business One solution based on all those parameters that we can see above and that must be filled by the user since he is the only one who knows his processes plus the experience of the partner that accompanies him in the project.
Once an estimated result has been obtained, it is advisable to round up in terms of "memory core" since HANA works and is sold to the customer in 64GB core.
Therefore, here it is advisable for the client to acquire 2 memory core for a total of 128GB and thus face the necessary resources that are estimated to install the solution.
This is merely referential and each case must be analyzed technically and functionally in detail.
Sizing helps the reader to get an idea of how this process is generally done.
So continuing with the theme we could define this project in 2 phases:
1. A phase where the pre-migration plan would be carried out.
2. The total migration of the product.
Project teams
Before continuing, it is good to put names and surnames to the macro-tasks and in this way define the 5 fundamental actors that generally make the scene in projects of this type:
1. The Client, which we could call the Product Owner (PO)
2. The technical team that will lead the project ( TT).
3. The functional team (FT).
4. Sales ( SALES ) (usually they are only at the beginning of the project and are not seen anymore).
5. Addon Developers (DEV)
Pre-project
Based on this we will define this pre-migration plan with its associated actors at the end:
1. Determine the current resources with which the system currently operates. A detailed technical review in which the operating system, SQL Server version, and product version are determined. (PO)
2. Review the SAP Business One HANA Product Matrix to see if the version that the customer has is directly migrable or if it needs a mini-upgrade project before it is operational and thus if it can be migrated to HANA. (TT)
3. Review the addons with which the client currently works. This is essential, since they sometimes determine if the migration is feasible or not and the delay that this could have in case the developer of the addons does not have an operational version in HANA or the development of the new add-on is needed correspondent. (FT) & (PO)
4. Make an inventory of the number of reports in Crystal Reports, formatted searches, queries generated in the Query Manager, etc. and how all these affect the processes defined in the tool. Here in this step, having already a defined inventory and with the expertise of the functional team, the necessary hours that such activities will consume within the project should be calculated. It is also prudent to take into account and discuss it with the client if some of these reports will be migrated to the new Modeling reports that HANA uses and that are the product evolution itself (FT).
5. Point 3 is critical and cannot be overlooked. Many migration projects have been stopped for not having considered this survey in a timely manner, causing many inconveniences to all parties involved. (FT) & (PO)
6. At the functional team level and the client, they must determine the new needs to be implemented in HANA by doing a Sizing process. This is nothing more than previously explained to determine the amount of memory to be used by HANA (FT & TT & SALES)
7. One point to consider is licensing based on the number and types of users (professionals and others) that will be required in the client's new solution ( SALES ).
8. The client must be clear about where the new solution is going to work, if it will work in their current Datacenter (if they have their On-Premise facilities) or in their own cloud if they have contracted it. This is essential because sometimes clients are not clear that both solutions (SQL and HANA) must coexist on the same network at least for the duration of the migration project (to avoid latency issues and other technical peculiarities to consider in the migration process). For this, you must provide exactly the necessary resources estimated by the Sizing process, added to that the expertise of the technical team so that the installation of the new product is as expeditious as possible within the project.(PO)
The migration project
Having those points very clear and resolved in an action plan, it could be said that we entered what would be the essential points to put together a project plan with macro-tasks:
1. Identify the migration path and the horizontal architecture given the current version in which the client is (what is specifically 9x PLxx? See point 2 of the pre-phase) and the target version of the client's SAP Business One system (HANA 10 PL03? It is always necessary to validate if you are going to go to the latest version available) (FT & PO)
2. Hardware configuration and installation of SuSE Linux Enterprise for HANA and SAP Business One installation. (PO & TT)
3. Validate connectivity (with minimal latency) between the current SAP Business One SQL environment with the future SAP Business One HANA to be installed (they are on the same network / VPN / VPC). Note: you cannot do migration if both environments do not see each other. In case they are not seen, the client must technically resolve the matter. (PO & TT)
4. Validate environment provided by the client for the installation of SB1 HANA 10 at the level of processors, memories, file systems, etc. If the validation of the technical team does not pass, the client must adjust the requirements until achieving the desired values and configurations. (PO & TT)
5. Request the SAP S-User customer so that the technical team can download the required software and then install SAP HANA and SAP Business One, version for SAP HANA. (PO & TT)
6. Request and install the license keys for SAP HANA and SAP BUSINESS One, version for SAP HANA. (PO & TT)
7. Review the SAP notes to see if the version of B1-SQL to be migrated is compatible with the target version HANA B1 (The migration path and the architecture of the system landscape were identified given the current version and the target version of the SAP Business system One of the client
i. [If applicable] It will be necessary to update the B1 database in the version of SQL Server for the migration to remain operational. (TT)
8. Perform database migration from SQL Server to SAP HANA .
i. Migration test
1. Make a backup of the current productive database (TT)
2. SQL Server Connectivity Test - HANA (TT)
3. Schedule after-hours migration test on copy (TT)
4. See if the process was successful, but rather apply notes that came out in the migration test with the functional team to correct any problems that may exist and do not allow the database to be migrated. (TT & FT)
5. Repeat migration test. Go back to 4 if there were errors. (TT)
6. If everything is OK then apply corrections in the customer's production database. ** Downtime time is measured here ** (TT)
7. Make a backup of the customer database in SQL Server (TT)
ii. Perform migration to HANA (coordinated after hours). (TT)
9. Perform the B1 database upgrade in post migration to SAP HANA. (TT)
10. Initialize the company schema for analytical functions with the SAP Business One Analytics Administration Console on HANA. (TT)
11. Migrate customization related to SQL query in:
i. SBO_SP_TransactionNotification (Electronic Invoicing and check if it is implementable and see if it applies to allocate developer / functional resources for migration ) (FT)
ii. User-defined queries, formatted search, alerts and reports, etc. (FT)
12. [Optional] Create reusable models or extend the semantic layer for analytical scenarios (FT & TT)
13. Migrate Analytics
i. Crystal reports. (DEV & FT)
ii. Dashboards configuration, etc. (FT)
14. Migration of addons and tests of their functionality in the new environment (DEV & FT)
15. Installation of the new SAP Business One HANA clients by IT staff on the client stations or, failing that, on the Terminal Server. (PO or TT)
16. Functional tests with users and tests of the new environment . (FT)
17. GO - LIVE (PO with FT & TT support)
To close…
Migration projects if they are done in a well-planned way and taking some of these premises indicated here (which were taken from the SAP guide for this purpose and the good practices in this type of projects) are mostly successful.
I believe that all the points mentioned are valid to take into account and even essential in many cases if we want to achieve certain success.
There are many technical considerations, but there are more at a functional level that are very important to take into account and these functional considerations are more reflected in the migration test process.
In general, if the client's SAP Business One SQL Server installation (it always has years of intensive use), bad practices were made at the level of user fields, user tables and own developments that compromise the good practices indicated by SAP, unfailingly They are going to emerge in the migration test process as an alert for correction, even without letting us continue in the process. We will not be able to carry out the migration if we do not correct what the wizard tells us.
Precisely this test is to validate everything bad that could exist at that level and that the client, with the support of the functional team, must correct to solve this situation by applying SAP notes that the same assistant dictates based on the errors found in the way.
Once these errors are solved, the migration process is executed again (as long as we validate all the technical aspects related to the process and that it is necessary to review in the product administration guide) in order to avoid problems and achieve the expected result of migrating SQL to HANA.
No comments:
Post a Comment