The aim of this blog is to document the development path from the existing V2 release of the Migration Architect software to the upcoming V3 release. To that end, I figure a little history of the existing software (and what went before) is in order.
When I joined Vamosa (prior to being part of T-Systems) back in 2008 there was an existing in-house software product named ‘Vamosa Content Migrator’. This was a traditional Client/Server based product backed with a relational DB. The server side was implemented in Java, while the client was implemented in C# (.Net Framework v2). Communication between client and 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 in the works.
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 role of development and maintenance of the existing software. It became clear quite quickly that there were some major issues with both the older v2 platform and the newer v3 platform…
- v2 was effectively dead – many of the components and libraries that had been used in the development were either no longer around or 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
It seemed to me that the best scenario 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 had been 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, moving to NoSql gave 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 (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 were that all existing functionality had to be present in some form, unless there was a good reason for dropping or changing it and that 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 the 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 3rd child!
With design goals that include words like:
- Cloud Ready
- Cross Platform
- Dev Ops
- Scale Out
- Continuous Integration
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 specializes in content migration to cloud, on-premises and hybrid cloud systems. With two decades of customer migrations, 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.