Enterprise Customer Data Platform

Technology Transformation: Do’s and Don’ts

Published On -

Quaero passed a major milestone on May 11th, 2020.  On that day,  we literally pulled the last plug out from our data center and completed our migration to the cloud (AWS).  The accompanying picture memorializes that moment.

It has been a remarkable journey over the last few years as we have successfully  stayed ahead on the technology curve to support our customers, built a world class Customer Data Platform (CDP) and simultaneously transformed our internal processes.  

Getting the pace of technology change right to manage our clients’ customer data was tricky. Our clients have  to cater to their consumers’ behavior and preference along with complying with industry regulations and privacy rules. As a  strategic partner, we had to bring appropriate  solutions to our customers, constantly innovating to transform technology, improve efficiency and reduce operational cost. 

The timeline below highlights the  major technology transformations we have gone through in the last decade.

The learning from these transformations has been incredibly valuable, sometimes painful but necessary, and rewarding for our entire team, who have had the opportunity to constantly learn new skills and stay abreast of the latest technology trends 

Apart from the technology,  there is much I have personally learnt through this journey and  feel is worth sharing: 

Stakeholders’ Buy-in

Have clear business objectives outlined and socialized with your business and technical stakeholders (both within the company and at the client) and get their buy-in. Keep people supportive of the organization direction close, but keep the naysayers even closer.  Understand their perspectives and watch for signals that may potentially derail a project.  

Budget and TCO

Define total cost of ownership (TCO). It may include software licenses, annual maintenance, ongoing operations cost, including people and infrastructure, hardware, cost of implementation, and potential savings from discontinued operations. Don’t buy into vendor’s sales pitches on TCO and idea of zero cost of ongoing resources to maintain an environment. Verify these independently, by talking to real customers who have had the experience


There are choices when it comes to new technology. Evaluate vendors and conduct POCs  with a defined use case for a time bound of 4-5 weeks max, to finalize a vendor and learn the technical nuances and pitfalls. 

The use case should include urgent and/or high priority business objectives, technical considerations and  support considerations. Be prepared to document technical details of your current environment such as size, data volume, no. of users, query patterns, data complexity. The more prepared you are, the better outcome will come out of the POC.

Scoping and Planning

For migration projects, consider a plan with 40% design, 30% migration/development, and 30% testing as a general guideline. Most  design items are related to testing  complex logic on new tech, validating rules, refactoring code, and testing performance. Have clear visibility on these items prior to developing a project plan. Don’t spend time  developing a detailed plan until the design phase is ready because most likely it will change. 

Avoid “agile planning”. It’s a myth. Planning needs to be a waterfall, but the execution needs to be agile. You need to have a plan with a gantt chart of epics, tasks, dependency, resources and dates. 


Define success criteria, roles and responsibilities, and articulate them clearly within the team

Identify the right resources, aligned to roles and responsibilities, with the right skill set. While your team may be able to handle most of the technical work, you need someone who has deep expertise on the new technology. Deep expertise means someone who has made a  living working on that technology. Engage a managed service provider,  if they are available.

Prepare for Project Delays

This may sound strange, but it’s real. The question is not whether the project will be delayed, but when. The key is how early you can detect the delay,  so  you can adjust the execution plan and communicate accordingly.

Resist the temptation to add more people to mitigate the delay. In most cases, it doesn’t work.  On the contrary, it may frustrate the existing team as they need to onboard  new team members while working on a tight timeline. 

Parallel Run

Plan for ample time for parallel environments and have end-users engaged to validate in both environments. In addition, you should set expectations with the  business for a variance between the two environments. It is unlikely the result from both environments will match 100% due to many factors.  Setting this expectation early, will help smooth acceptance later on. 

Prepare for a go-live day

Schedule go-live over a weekend or long holidays to minimize business impact. 

Plan the team on a rotation basis, round the clock to support migration and validation


Align the project manager, account manager, product manager, and executive sponsor to communicate internally and externally to the right audiences. The communication format should be well structured and appropriate for each audience, to minimize confusion or misunderstanding

Celebrate Success

Don’t forget to celebrate!. Take a few days break before bringing the team together for a retrospective. There is usually plenty of feedback. Listen to them, acknowledge them, document the lessons and remember to incorporate them before the next project. 

During the project, remember to set aside some time for fun, try and keep the team in good humor and keep motivating the team. At the end of the day, this is just software, so don’t let it overrun your life. 

Want to discover more?