Advantages, Disadvantages, and Process to Transition to Enterprise Architecture
Author: Eric Vasbinder
Applicable ERPs
Vista
Customers of our Vista ERP solution range from small, 5-10 user customers with only a few million in revenue every year, all the way up to substantial, publicly traded organizations with hundreds of ERP users and multiple billions of dollars in revenue every year.
For the most part, the standard architecture used for customers in our cloud is quite effective, providing a good balance of performance and efficiency. However, for some of our largest customers, an enhanced, horizontally scaled architecture is recommended to allow for faster processing of reports, payroll batches, AP analysis, and integrations to third party analytics and reporting tools.
To that end, back in 2020, we created the Enterprise Architecture deployment model for our hosted Vista ERP customers. This architecture, available to customers meeting certain criteria, provides a substantially enhanced and distributed hardware footprint for our most demanding customer use cases.
To understand why Enterprise Architecture is beneficial for our most demanding customers, we must first understand the Standard architecture used for cloud environments.
Please see the following FAQ article for details on our Standard Architecture: Standard Architecture for Vista
For customers whose overall volume of concurrent activity and/or batch transaction volume exceeds that which our Standard Architecture provides, we offer an Enterprise Architecture option for the Vista ERP cloud. This deployment model consists of the following components:
The "-DB1" box: This is a dedicated virtual machine, allocated specifically only to house the Vista records and attachments database instances
The "-APP" box: This is a dedicated virtual machine, allocated specifically only to house the Vista application server
The "-CN1" box: This is a dedicated virtual machine, allocated specifically to only how's the Crystal Reports engine.
Please note that some environments may have up to three additional Crystal Reports nodes in a cluster ("-CN2", "-CN3", "-CN4"), depending upon the level of Crystal reporting demand present in the environment.
The "D1" box: Providing support for User Profiles.
The "D2" box: The Vista Web (formerly Keystyle or HFF) application and web server
The "-VRL" box: The reverse proxy server that enables Vista Remote Link to provide HTTPS based conductivity for Vista rich clients into the Vista database when hosted in our cloud
The "MS1" or "TS1" box: The Azure Virtual Desktop (AVD) or RDP Terminal Services box. For use when end users need lower latency access to the Vista client itself when connecting from connections with substandard latencies above 30-40ms, such as satellite internet (e.g. Starlink).
Please reach out to your Trimble ESB, Support, or Account management teams for a copy of our Architectural Diagram if needed. Please note that this requires a mutual NDA, which most customers have as part of their customer contracts with Trimble.
As you can see, based on the above architectural details, the Enterprise Architecture deployment model enables us to split the processing of database queries from application logic, as well as moving the processing of Crystal reports from the application and database server. This allows us to horizontally scale the operations of Vista, as well as allowing for more clean and efficient allocation of resources during heavy operations.
Enterprise Architecture has a number of caveats and changes that will occur when moving to this new deployment model.
Due to the significant differences in the naming and internal structure of EA environments as opposed to standard environments, using EA requires that Trimble set up a brand new, Enterprise Architecture environment, to which customers can move
Due to the move to a completely new environment, there will be a new server name and static, private IP.
This requires that all third party applications that are pointing to the current Vista DB IP be repointed to the new static IP.
As this process is, in effect, like a miniature transformation, there is a need for a full testing cycle to review custom reports, third party applications, and other tools to ensure they work properly with the new server environment.
All connectivity with third party applications that use an IPSEC VPN to connect, or that use the Vista AppXchange API will break during the move. The process to correct these breaks is different depending on the integration in question and the type of connection it uses to Vista.
Though, over the long run, Enterprise Architecture (EA) environments are uniformly more performant under concurrent load when compared to Standard Architecture environments, there are, from time to time, instances where Vista will perform more SLOWLY in the new EA environment. These can be corrected through troubleshooting and evaluation of each area of performance concern.
The cause of this is often related to database version differences between the old SQL server in your old standard architecture environment and the new SQL server in the new EA environment. Given the strong possibility of a SQL server version difference, factors such as compatibility level differences in query optimization, the need to reconstruct indices in a new fashion, and other SQL version specific optimizations could come into play.
Given that possibility, the test plan should critically include the need to check performance and functionality of batch jobs, data entry, and reports; custom reports in particular.
Here is a specific example: Some customers in the past were upgraded from SQL 2016 to SQL 2019 and thus encountered significant performance issues with custom reports, info tab field validation refreshing and lag, and batch job processing delays caused by legacy queries in reports, legacy triggers, and legacy stored procedure optimizations.
Those issues needed to be addressed by SQL server compatibility version changes in the short term, then intertwined with longer term projects to rewrite those custom reports, triggers, and stored procedures to be in line with more modern SQL server version expectations. In some instances, the ONLY solution, either immediate or longer term, is a complete rewrite of the impacted queries, stored procedures, customizations, etc. or even the elimination of legacy triggers from Vista entirely.
Your testing cycle should include time to not only review these items, but the time necessary to correct these items if they prove to be applicable to you.
Moving to EA requires creating a brand new, EA environment for the customer and then moving the customer's Vista instance to that new environment. This new EA environment has a larger footprint and associated significantly increased costs for Trimble. In addition, the Enterprise Architecture solution itself only provides performance benefits to customers of a certain size and level of activity and higher.
As such, there are certain requirements that must be met in order for a customer to qualify to be upgraded to Enterprise Architecture. First and foremost is that any customer who wishes to move to enterprise architecture MUST purchase an upgrade to the Bronze tier or higher of the Enterprise Solution Bundle (ESB) for Vista, known as the Vista Enterprise Infrastructure and Support (VEIS), or VEIS ESB.
The project to move to Enterprise Architecture (EA) will be a complex and extensive effort, moving the customer from their existing cloud environment to a brand-new EA environment. The process itself, since it requires a full move of the entire customer’s Vista and Vista Web ecosystem, repointing of all third-party integrations, etc. is very similar in terms of time and effort for an on-premise to cloud transformation. We anticipate 3-6 months of time at a reasonable estimate.
Due to the complexity of such a move, the customer must not only be on at least the Bronze tier of the Vista ESB program but must also purchase an implementation services project to allow for Trimble to assign uniquely skilled, dedicated engineering and project resources who are familiar the process of moving customers from one environment to a completely new one. This will usually be added to the ESB contract as a separate SOW.
Please reach out to your account manager for more details on the estimated pricing of this project.
The following are the high level tasks to move to Enterprise Architecture (EA):
Customer and Trimble Account Team: Ensure you have purchased the Bronze or higher Tier of the ESB.
Trimble: Stand up brand new EA environment.
Trimble: Coordinate with customer to begin project to move to Enterprise Architecture.
Trimble and Customer: Set up weekly migration calls for the project to migrate to EA.
Trimble and Customer: Begin testing of end user workflows, reports, etc. as well as third party integrations into the new EA environment.
Trimble and Customer: Once all critical functions have been tested and approved as working in the new, pre-production EA environment, schedule time to perform final data copy into new environment.
Trimble: Perform final data copy into new EA environment. Turn off old servers. Perform final QA checks.
Customer: Perform final QA validation with internal IT / QA staff.
Customer: Hand off new EA environment to end users.
Customer and Trimble: Coordinate with post-cut over issue tracking and correction, meeting at least 1x per week for two weeks post cut over.
changelog
Wednesday, 16 September 2026 at 11:13PM:
Reworked Caveats section to be much more detailed about what can be encountered, mitigations, causes, etc.
Tuesday, 16 June 2026 at 03:39PM:
Split Standard Arch into a separate FAQ article.
Thursday, 23 April 2026 at 02:46PM:
Initial Posting