Portfolio

SoftLayer to Azure migration

Cleaning services company cuts costs and boosts uptime with Azure App Service

Influential Software reduced costs and ensured uptime by modernising a mission-critical application through IBM SoftLayer to Azure migration.

Technology representing IBM Softlayer to Azure migration

Executive brief

IBM SoftLayer to Microsoft Azure migration

Our client is a UK-based provider of cleaning services for business, schools, and vehicles. Influential Software helped the company migrate its Java-based vehicle management application from IBM SoftLayer to Microsoft Azure. This SoftLayer to Azure migration project had the following benefits:

reduced app hosting costs

no application downtime

more flexible scalability

increased app performance

Want to learn the full benefits of IBM SoftLayer to Azure migration? See the project story below.

The full story

Purple arrow encouraging readers to scroll down for the rest of the SharePoint Online intranet development case study

The challenge

Application downtime and low scalability

At the time of this project, Influential Software was providing ongoing technical support for the company’s vehicle management application. This software was used to manage over 500 contractors serving 150 automotive clients on a daily basis.

 

But the Java-based application, hosted on IBM SoftLayer, was experiencing difficulties with downtime and lack of scalability. With the vehicle valeting business growing rapidly, the company saw these technical issues as a barrier to onboarding new clients.

 

The issues with SoftLayer hosting were as follows:

 

  • any code changes required bringing down the whole app, meaning changes were not possible during business hours
  • we also had to bring the app down to meet changing demands in performance, CPU, memory, and hard disk space

 

These factors made SoftLayer an unsuitable choice for the company, which wanted the application to flex and adapt quickly. Having identified these issues, our support team set about presenting a more effective solution.

The solution

Achieving SoftLayer to Azure migration

Based on our Azure cloud expertise, our support team recommended that the company migrate the application to Azure App Service. Microsoft’s increased support for Java on Azure in recent years gave us plenty of options for migration.

 

A major advantage of Azure App Service was the ability to deploy new code with zero downtime, during business hours. We achieved this through Azure deployment slots. These slots allow us to deploy to a copy of the live application and then swap the two environments seamlessly. In this way the new code goes live and nobody sees any disruption.

 

A second reason to choose Azure was the ability to scale each component of the application individually. This meant we could flex to meet demand quickly, without having to bring the whole application down.

The benefits

Full uptime and room to grow

Only days after the SoftLayer to Azure migration, we successfully scaled up the application’s hosting capacity without disrupting business hours. This has given the company the freedom to take on as many new clients and contractors as it desires.

 

On top of the benefits mentioned, moving to Azure App Service also provides intuitive Application Insights for our support team. Rather than having to trawl through log files to find issues, we can see them faster in visualisations and alerts. That extra speed on our side provides the company with better value from the support hours they purchase from us.

 

Overall, the decision to migrate from SoftLayer to Azure has brought increased app performance and reduced hosting costs.

Work with cloud migration experts

We help organisations of all shapes and sizes migrate to the cloud. Whether it’s a bespoke application or third-party software, our cloud team will support your transition every step of the way.

Info

5th January 2021
IBM Softlayer, Azure, migration, Java, support

Privacy Preference Center

Necessary

Advertising

Analytics

Analytics cookies collect information that is used either in aggregate form to help us understand how our Websites are being used or how effective our marketing campaigns are, or to help us customise our Websites for you.

Google Analytics
The cookie _gcl_au is used by Google Analytics to understand user interaction with the website.

For example, in order for Google Analytics to determine that two distinct hits belong to the same user, a unique identifier, associated with that particular user, must be sent with each hit.

The analytics.js library accomplishes this via the Client ID field, a unique, randomly generated string that gets stored in the browsers cookies, so subsequent visits to the same site can be associated with the same user.

By default, analytics.js uses a single, first-party cookie named _ga to store the Client ID, but the cookie's name, domain, and expiration time can all be customized. Other cookies created by analytics.js include _gid, AMP_TOKEN and _gac_. These cookies store other randomly generated ids and campaign information about the user.

Google Analytics
_gcl_au, _gid, _ga, gtm_preview

Other

WordPress uses cookies for authentication. That means that in order to log in to our WordPress site, you must have cookies enabled in your browser.

There are two types of cookies set by WordPress.
1 — Session cookies — These are ‘strictly necessary’ cookies as WordPress will not be able to function without it.
2 — Comment cookies — These are not ‘strictly necessary’ cookies and are set when users leave a comment on a post.

Wordpress Session cookies:
Users are those people who have registered an account with the WordPress site.
wordpress_[hash]
wordpress_logged_in_[hash]
wordpress_test_cookie
wp-settings-{time}-[UID]

Wordpress comments:
Comments are usually turned off by default.
If by chance they are still active on a post, asides being turned off when spotted, data from these are not saved by Influential.
- When visitors comment on a post, they too get cookies stored on their computer. This is purely a convenience so that the visitor won’t need to re-type all their information again when they want to leave another comment. Three cookies are set for commenters:
comment_author_{HASH}
comment_author_email_{HASH}
comment_author_url_{HASH}

Wordpress, Intercom
comment_author_{HASH} comment_author_email_{HASH} comment_author_url_{HASH} wordpress_[hash] wordpress_logged_in_[hash] wordpress_test_cookie wp-settings-{time}-[UID]
intercom-id-[app_id],intercom-session-[add-id]