The aim of this blog is to document the development process from the existing V2 release of the Migration Architect software to the upcoming V3 release. To this end, a little history of the existing software (and the software that was used before this) is in order.
When I joined Vamosa (before it was part of T-Systems) back in 2008, there was an existing in-house software product called ‘Vamosa Content Migrator’, which was a traditional Client/Server based product backed with a relational DB. The server side was implemented in Java, while the client side was implemented in C# (.Net Framework v2). Communication between the client and the server was achieved with ActiveMQ. At that time, I believe the software was at v2.9 (or thereabouts).
By the time Vamosa was acquired by T-Systems, in October 2010, the software was at v2.13, with a major update to v3 on the horizon.
V3 never quite made it to a production release, and during the move to T-Systems, the entire development team moved on to pastures new.
Although employed as a Migration Consultant, coming from a Software Development background, I found myself taking on the development and maintenance of the existing software. It quickly became clear that there were some major issues with both the older V2 platform and the newer V3 platform – these were, notably;
- V2 was now effectively dead – many of the components and libraries that had been used in the development were either no longer around, the licenses had expired or could not be found. It wasn’t possible to build either the client or the server components
- V3 was basically vaporware – lots of time and effort had gone into making it look nice, but it still had all the same fundamental problems that V2 had had.
It seemed to me that the best option would be to start again, and address those issues from the ground up.
After a lot of talking and white-boarding, my one-man development effort effectively started around October 2012.
The major design decisions that were taken were:
- the entire platform would be built on .Net using C#
- my development background was Delphi and .Net
- the back-end database would change to a NoSql document database, RavenDB (also built on .Net)
- the main performance bottleneck in the existing platform was related to the database design – therefore moving to NoSql would give us the flexibility required without the performance hit
- the rules processing engine would remain Python-based, but switch from Jython (Python build on the Java stack) to IronPython (Python built on the .Net stack)
- minimal impact on existing scripting (which is the backbone of the migration processing engine)
- the key concepts and conventions within the product would remain as close as possible to the existing software, unless there was a specific performance/stability reason for changing them
- key for an easy transition of the existing users
The key requirements for the content management migration were that all of the existing functionality had to be present in some form, unless there was good reason for dropping or changing it, and that the system performance had to be at least on a par with the existing system.
Here are some of the key moments in the timeline between then and now:
- 2012-11-19 : Initial Git commit of ‘New Content Migrator
- 2012-12-20 : First prototype demo of the new software to existing users
- 2013-05-17 : Add import/export functionality – a key component to allow local development / remote execution
- 2014-01-18 : First mention of Migration Architect as the product name
- 2014-01-30 : First v1 release (with an installer) appears
- 2014-11-21 : Auto update functionality implemented
- 2014-11-27 : REST API implemented
- 2014-11-28 : Script testing functionality implemented
- 2015-03-31 : Time-based licencing implemented
- 2016-09-22 : v2 release appears, introducing full end-to-end SSL encryption support
- 2018-10-18 : v2.110, the most recent release, including advance script testing functionality
And now we find ourselves back at a crossroads having decided to embark on v3 – the difficult third child!
With design goals that include terms like:
- Cloud Ready
- Cross Platform
- Dev Ops
- Scale Out
- Clustering
- Continuous Integration
- Containers
- Micro-services
- Distributed
To name but a few!
Anyway, that’s way more words than I had intended, so be sure and tune in next week… Same Bat-time! Same Bat-channel!
Take the next step!
A division of T-Systems, Vamosa Technologies specialises in content migration to cloud, on-premises and hybrid cloud systems. With two decades of customer migration processes, Vamosa Technologies has experience with a comprehensive range of leading enterprise content management systems. To learn more about services from Vamosa Technologies, please visit our case studies and whitepapers or contact us.
