Migration of the Customer Portal of a Regional Energy Supplier

MacBook displaying LEW customer portal menu showing different functions.

Key Facts


As part of a cross-functional collaboration between sales, customer service, SAP development and web development, end customer processes are to be optimized and digitalized as part of a project. The first step was to create a technical basis for this. Only then can the future measures be easily implemented.

Situation before

Customers can already access their contracts and invoices digitally via a separate web application. They also have the option of carrying out certain functions, such as changing bank details. Unfortunately, the direct link to the SAP system means that the customer portal can no longer be accessed in the background during maintenance work. In addition, the previous identity provider is inflexible and no longer state of the art. It is therefore to be replaced. The separate application also runs on a different server and must be maintained separately, which increases maintenance costs. A central point that caused major problems with the previous solution is the meter reading of all customers between Christmas and New Year. This leads to a considerable load on the web application and the systems involved.


The following objectives were identified:

  • Planning a software architecture that takes into account non-functional requirements such as greater reliability, fault tolerance and scalability
  • Development of a technical basis that enables flexible expandability
  • Reduction in the number of customer service calls
  • Increase in the online usage rate
  • Gradual migration so that there are no interruptions to ongoing operations
  • Reduction in maintenance costs


The goals that were set led to several challenges and questions. To ensure a smooth migration, it was first necessary to clarify how to deal with the customers. The transfer of accounts from the old identity provider could not be carried out without further ado, as the passwords could not be transferred. This problem was overcome with the help of a migration process and the transfer of the transferable components of the user accounts.

It was clear early in the project that the customer portal should be integrated into the website’s software environment to drastically reduce maintenance costs. To achieve this, the relevant components had to be re-implemented in this environment – both in the front end and the back end. In addition, the source code must be clean and tested. This reduces the occurrence of bugs and ensures future maintainability.

Dealing with peak loads was also an important aspect. To better deal with these, processes for asynchronous communication were implemented using a service bus. An additional advantage is the elimination of the direct dependency between the web and SAP systems. In the event of maintenance work, the web application can continue to work with the data already retrieved and temporarily stored in the SAP system and still offer the user the desired functionality. Messages that could not be delivered due to interrupted communication between the two environments are retained and delivered as soon as communication is possible again. To control the utilization of the web environment as well as possible, a microservice approach was used in the backend, which allows the individual scaling of individual services. This ensures that the available resources are optimally utilized.

To make the new solution available to customers quickly, an iterative and agile approach was chosen for the implementation. Customers should initially be able to access the new site via the new login but will be redirected to the relevant location in the old system with a corresponding link for functions that have not yet been moved. This had the advantage that it was possible to determine very early on in the development process how well the authentication and migration processes to the identity provider were running. This resulted in a minimum viable product (MVP), which was made available as such to the end customers to involve them in the development at an early stage.

As part of the migration, the “Mailjet” mailing system was also connected to make the sending of emails traceable and reduce incorrect spam categorization. A great side effect: the specialist departments can create and edit email templates quickly, flexibly and without developer support.

The introduction of a new program and a new identity provider can result in security risks. To test the software, a penetration test was carried out before deployment and the findings listed were rectified.

My Contribution

As an software developer in the web development department, I was actively involved in both the design and development. This included planning and defining the software architecture, implementing the business logic in the backend and, due to my SAP background, connecting the SAP functionalities. It was particularly important to me that data and functions could be accessed independently of the availability of the ERP system. I achieved this by using caching and a messaging system, among other things.

With such a system, it is important to ensure that the data is correct. That’s why I defined precise rules for validation in consultation with my SAP colleagues. These are enforced via the domain-driven design used in such a way that there can be no object that is in an invalid state.

To ensure that everything worked well together in the end, I was in close and interdisciplinary contact with colleagues from SAP development, customer service and sales. Among other things, this enabled me to ensure that the SAP functions were connected quickly and smoothly and to react quickly and flexibly in the event of an error. To improve communication with other departments, I visualized technical processes using diagrams.

If there were bottlenecks in the front end, I supported the development of the React components and logic.

Technologies Used

A variety of technologies were used to implement the application. The backend was developed in C# and .NET Core, while the frontend was mainly developed in React with TypeScript. I used the ASP.NET framework (Web API) to develop the REST and gRPC interfaces. To map the asynchronous processes, I used NServiceBus, which ensures the delivery of messages even in the event of an error. I used the existing Microsoft SQL Server Cluster to store data. I used the Entity Framework for development.

User management was solved by Azure AD B2C in combination with OAuth, which meant that a managed, easily configurable solution was used for the first time. Further software metrics and logs are recorded with Application Insights. Real-time updates to notify the user or update the front end were implemented via SignalR and Azure Functions.

Customer Benefits

By implementing the migration, new functions can now be added easily. The improved scalability enables the sales department to attract more customers to the portal without having to worry about performance losses. Meter readings are reliably recorded online and reduce the number of customer service calls. The migration has increased the use of online services by 55 % and availability by over 95 %. The development of customer portal users even exceeded the customer’s forecasts.

You have a similar problem, that you want to have solved by an experienced engineer? Feel free to get in touch with me.