From: Sandra Plyar (CTO)
To: All Global Corporate Employees
Subject: Launching [Sail], our new customer system.
Date: March 5, 2026
I’m excited to announce that [Sail] is in production, and wehave deprecated Acropolis. [Sail] is our new unified solution for managing ourcustomer profile data and how they authenticate on our website and in-store,and it provides a centralized mechanism to store customer data. We workedintensely over the last nine months to complete this migration with minimaldisruption to existing systems. Go to [Sail].armoso.dev to see for yourself.
We built [Sail] with modern cloud services, enabling us tospeed up the pace of innovation within Armoso. We’ve experienced delays andhiccups in report generation, customer support calls because of datasynchronization issues, and the frustration of teams that had to wait months tobuild and deploy features and campaigns.
[Sail] uses a flexible schema system, allowing multipleteams to store data for their use cases without having to wait for approvalsand reviews, while maintaining the integrity of the system. It uses adistributed architecture, providing exceptional reliability and availability.Gone are the days of data synchronization issues. We also provide a built-inmechanism for data history, making it simpler to audit and revert any changesapplied to customer information. Finally, we built [Sail] to be “privacy-aware,”limiting access to user records and even field-level access control. This makes[Sail] GDPR and CCPA compliant and allows us the flexibility to handle futureregulations without having to rebuild or re-architect our services.
This was a team effort with 18 engineering teams working toidentify, collect requirements, and replace the old Acropolis database. Wedeprecated nine services and 12 tools, and we’ll reduce our infrastructurespend by more than $6.5 million a year. You can visit [Sail].armoso.dev toaccess user data and reports and find the documentation for tech teams to use[Sail]'s APIs and data dictionary.
Sandra Plyar
Chief Technology Officer
Internal FAQs
Q1: What discussion are we having today?
We are seeking executive approval and budget funding toreplace the existing Acropolis database system with a modern architecture.
Q2: What problem are you solving, and who’s the customer?
Our primary customer is Armoso’s customers. They’ve had asubpar experience with our systems because of an outdated architecture. It’snot unusual for updates to passwords and email addresses to be unintentionallyreverted. Last year, 17.3 percent of customer support inquiries related tocustomers failing to log in to the website. We had 0.27 percent of ordersdelivered to the wrong address because of synchronization issues aftercustomers made an update to their shipping address. Our customers see a 2.7s additionallatency (p99) for each page that requires access to the customer data (inAcropolis). Our product design teams limit their ideas on mobile and the Web toavoid accessing this information, leading to unpersonalized experiences.
Besides our primary customers, we have 25 teams who built117 services on top of Acropolis to support our operations, from accounting tomarketing, from customer support to fraud detection. The current architectureis brittle and requires changes to go through a 12-week review processinvolving eight teams. These stakeholders must plan nine to 12 months ahead ifthey need any change to Acropolis. Finally, our compliance and legal teams havebeen concerned about the lack of access control on the Acropolis database sinceit doesn’t support granular field and row access control. Today, engineers haveaccess to whole database tables, even though it’s not a business need.
Q3: What’s the solution being proposed?
We’ve evaluated and prototyped five different technicalproof-of-concepts based on assumptions of the requirements. We found severalviable solutions, and our choice is to use Azure Cosmos Db as the centralrepository, Azure Data Lake, and Azure Cache for Redis as the core services.Cosmos Db is pricier than alternatives. However, it provides a level of globaldistribution, API, and store flexibility, auto-scalability, and it's fullymanaged. We are also adding a database access layer through REST and GraphQLAPIs, and a new distributed caching system for any services that don’t requirereal-time data. We estimated that query latency will be less than 0.09s (p99)for real-time services like our mobile app, website, and customer support agentportal.
We’ll build a schema taxonomy that allows separate teams toown their pieces of the data, like customer orders, payment data, and messagetracking. Teams decide the data they expose to other services, whichtransformers apply to which data, and the syntax and semantics of their datadictionary. Each team will keep an up-to-date schema description at[Sail].amoroso.dev, making it easier for other engineers to understand what’savailable.
We are also building an integrated history, audit, andlogging layer so every update to any field in the database is tracked andstored for a period, configurable per field.
Q4: What are the migration plan and risks?
Migration will be the most complicated aspect of thisproject. We’ve done an inventory of the 117 services using Acropolis tounderstand how they are accessing the data, what data they are using, and howwe can minimize disruption to the teams that own those services. We intend tolaunch two temporary services to support our migration plan. First, we’llcreate a shim layer on top of Acropolis using our new API design. We estimatethis project will take four months to complete. Teams will then have ten monthsto move their services to the new API design. Second, we’ll build a datamigration tool that will use Acropolis as the source of truth but sync the datato [Sail] in near real-time. Then, we’ll move the read-only API requests to thenew [Sail] database, and at the cut-off date, we’ll move the read-writeoperations and turn off Acropolis.
We’ll be able to simulate these updates in our prod-testenvironment with customer data that is a day old. We will inventory tables andfields to understand if there are redundancies, or fields that were deprecatedbut we never cleaned up. For example, we currently store customer addresses inthree different tables (orders, profile, and payments). We’ll be able tonormalize these data without disrupting the services that use it.
We also have a risk around our team’s skill set. We’ll needto provide proper training and certification for our engineers, and we havenegotiated with PlusSight, a Microsoft Certified Gold Partner, for a series oftrainings over a two-month period. Our Microsoft Customer Success AccountManager (CSAM) has connected us with a Cloud Solution Architect (CSA) who willadvise us and validate our architecture.
Q5: What are the stakeholders’ concerns?
Our tech organization is 1,100 engineers, TPMs, PMs, datascientists, and designers. Leaders are worried about prioritizing the worktheir team needs to do against the other items on the team’s backlog. For thisproject to be successful, we expect the executive leadership to get buy-in fromall executives in the company. We will slow down work on new features while wecomplete this project. In Appendix A, we list the 117 services using Acropolis,a brief description of what they do, the migration needs, and a rough estimateof the effort.
We have also spoken to teams in marketing, customer support,billing, returns, compliance, and operations. Their concerns are around theimpact on their processes and tools. They want to know what's going to changeand how to prepare for it. They are enthusiastic and supportive of thisproject, given how much pain they currently experience with Acropolis.
Q6: How much does it cost to launch this project?
This is not a cheap project compared to other initiativesover the last three years. We expect the core team working on [Sail] to needsix engineers full-time, a dedicated product manager, and a TPM. We have threeengineers and a TPM dedicated to Acropolis today. We will allocate 60 percentof their time to work on [Sail], so we will need to hire another four engineersand borrow TPM from another team. Each of the 18 engineering teams involved inthe migration projects will require 1-2 full-time engineers allocated to thisproject for 12-15 months. Appendix B includes additional costs for training,travel, and third-party vendors that this project will affect. We’ll need torenegotiate or cancel some vendor services. Today, we estimate it costs $16million per year in infrastructure to support Acropolis, including personnel,and that moving to the cloud will cost $9.5 million per year, saving us $6.5Mper year starting in year three. Appendix B contains the financial model.
Q7: What happens if we don’t do this now?
The existing system is working, even though it has theproblems described above. It has become challenging to innovate and launch newfeatures, affecting our business’s ability to keep up with other retailers andbetter serve our customers. Our systems are near the limit of theirscalability, and it’s possible that if we double our customer base, theperformance issues will become unbearable.
Q8: What have you done so far?
So far, we have done five things: (1) Customer discoveryresearch with the 25 teams currently using Acropolis, including an analysis of10,000 customer support contacts, (2) Customer discovery interviews withbusiness stakeholders, (3) Proof-of-concepts for five solutions, (4) Discussionwith PlusSight and Microsoft CSAM/CSA, and (5) Wrote this PRFAQ and created adraft project plan.
Q9: What are the technical risks?
We have identified two major risks. First, it’s possiblethat we have not surfaced all the services that rely on Acropolis today, and atdeprecation time, we may break a service or a team's procedure. Second, wewon’t know the full performance limitations of this implementation until we aregetting near the launch. We need the data available in [Sail] and most servicesusing it.
For the first risk, we plan to migrate services to use theshim layer. We'll turn off direct access to Acropolis for a 72-hour periodwhile monitoring for increased error rates. For the second risk, we’ll be ableto identify any performance bottleneck when we have the full implementation onthe prod-test environment and are simulating full customer traffic.
Q10: Are there regulations that apply to this project that we need to becautious?
Yes, privacy laws like GDPR and CCPA apply to this project.Our SOC-II and ISO-27001 certifications also play a key role in our newarchitecture. Finally, we need to maintain our PCI compliance with credit cardand billing information.
Q11: When will we launch, and what are the key deadlines or milestones?
The key milestones of this project include:
M1 (3 months): Requirements collection, architecture, anddesign reviews
M2 (2 months): Provisioning and implementation of [Sail]
M3 (2 months): Acropolis-[Sail] Sync tool & shim layerfor Acropolis
M4 (6-8 months): Service migration to Shim layer and launchof [Sail].amoroso.dev
M5 (2 months): Full prod-test load on [Sail] andoptimizations
M6 (1 month): Launch
