Avoiding the Pitfalls of a Start-up Angular Evolution — Join Us on the Journey
Hay, I’m Anton and I work on the frontend team at Panaseer along with Florian, Jacopo and Julian. If you are wondering, I’m in the Levi’s shirt. Over the last two years, I’ve seen our platform and the underlying technology stack evolve a lot — in startup life 2 years feels like half a lifetime! Looking back over all the technical migrations we’ve been through, the Angular one stands out as both the most critical to the evolution of our frontend platform and the riskiest in terms of unknowns and potential impact on our customers.
Migrating a large enterprise application from AngularJS to Angular in a medium sized organisation is a large undertaking — in a startup it can sometimes feel like a near impossible task. That’s what we realised after setting aside some initial time in January 2017 to properly research the topic. Over the course of the following year, we gradually replaced and introduced some strategic technologies to help us, had some surprises both positive and negative, and even now, having kicked off the migration through a hybrid approach, we are continuously evolving the end goal and time frame.
This blog post series will chronicle different aspects of the experience of migrating an enterprise application. We’ll aim to shine a light on the good, the bad and everything inbetween based on our experiences. Hopefully, this will help you get to the final goal of being able to say “Yes we have migrated a complex production system to Angular” more quickly. Benefiting from the shortcuts we discovered and missing the pitfalls.
The Beginning of Panaseer’s Angular Journey
Google’s Angular framework has come a long way since the early days. Panaseer joined the Angular journey in 2015 on version 1.4.4 — back when AngularJS was still ruling all the Javascript frameworks and developers using directives were the cool kids on the block. Now it wasn’t as early as version 0.8 or AngularJS Beta x and I have to say I am always impressed when I meet people that can lay claim to having started that early, but it still feels like a whole other world back then.
2.5 years and more than a hundred thousand lines of Javascript code later and Angular is blazing through new major versions every other month and the framework landscape has had a few upheavals. Our platform however stalled at Angular version 1.5 — until earlier this year.
Some people might be wondering what took us so long?
Panaseer is a startup — we have a very technical team, but we don’t have an army of frontend developers at our disposal to throw at migrating the whole platform at a moment’s notice. With that limitation in mind and considering the fact that product and feature development has to go on, we had to take a slightly more considerate approach that started in the beginning of 2017. The first JIRA epic that surfaced related to the migration was “AngularJS Migration Initial Research”. Without some rough estimates and a clear view of potential risks and blockers we wouldn’t have been able to put together a convincing business case for an iterative approach to getting ready and diving into the migration work. Now, we didn’t spend a year researching 😳, but taking into account time spent taking steps to address specific blockers and feature development that took priority over the migration — we finally felt ready to go towards the end of 2017!
Why put in the effort to migrate at all?
I won’t repeat the reasons for migrating away from AngularJS — the other ~240.000 Google results on that question should provide a clear overview — instead I’ll focus for a minute on why we decided to stick with the Angular framework from our specific application viewpoint. It might seem like a surprising choice, when everybody else seems to be talking about React.js and Vue.js, but we had good reasons to stay on the Angular track.
Migrating is faster than switching
Even though migrating our platform from AngularJS to Angular is a big step with a multitude of breaking changes, it is still quicker than rewriting it in React.js or Vue.js. Yes interfaces, some patterns, naming and underlying concepts changed, but we put in the effort to base everything around components and make use of Typescript (couldn’t write code without it now!) in advance to align closely with Angular before even starting the migration. More info on that in an upcoming post on our preparations for the migration.
We’re not joining the framework switching fad
We are seeing companies switch to React.js for the mere reason that it’s the framework everybody’s talking about at the moment. However, just switching because React.js is the Javascript flavour of the year doesn’t hold as a business reason. As long as we are confident that the Angular framework is continued to be supported and evolving as the preferred framework for large scale enterprise applications, it holds as a great solution for us.
So many shared patterns and approaches
A lot of the goodies that people love about React.js (I’ll just mention a couple like Redux state management and reactive/functional programming patterns) are not exclusive to any one framework, but general patterns and paradigms. Most of them can be a first class citizens in Angular as well — so I don’t feel like we’re missing out.
Why throw away our Angular expertise
We have an existing team of developers with longstanding experience in Angular. We could probably spend the time to get familiar with React.js, but it will take a while before we are as efficient with React.js as we currently are with Angular. So in terms of making the best use of the resources we have available it made sense to continue with Angular.
After going through all of the reasons above the ones for switching frameworks completely didn’t seem like a supportable option.
Join us on our Angular Migration journey!
With all that out of the way you might still be wondering why we are writing a blog post series about this. All I can say is that it wasn’t a smooth ride for us and I want yours to be a joy! If you’re in the same situation as us, with an application running at FTSE100 and Fortune 500 companies, you know that taking down their browsers because you accidentally added an undocumented migration issue is not an option! We hit roadblocks along the way and spent hours searching through documentation and third party reports to iron out bugs, some smaller, others bigger. I don’t want you to encounter the same pitfalls that we did. I don’t want you to spend hours searching for the same answers that we already found. So join us and take an inside look at what it takes to migrate a large scale application in a small scale company!
Finally, here’s a preview of questions we are planning to answer in upcoming posts:
- How do you even start getting a large scale application ready for migration
- Upgrading with Downgrade Module — yes really
- How will I find my way with upgrading routes
- What key things did we wish we’d know at the beginning
Hopefully this will help you get through some of the initial hurdles more quickly and reach the goal of a successful hybrid application that can migrate in style and at a steady pace without putting any other development on hold.
