FAQs

It is a five-year evolution to a platform that is faster, more intuitive, and easier to maintain. Our core purpose is to upgrade our underlying technology and user experience while protecting the critical business outcomes your agencies depend upon. This is a deliberate, workflow-by-workflow process, not a single, large cutover.

Four primary benefits drive this transition:

• Improved Usability and Operational Efficiency: A modern, intuitive interface streamlines workflows and minimizes manual input. By meeting contemporary user expectations, the system simplifies training and serves as a key driver for workforce retention.
• Faster Updates: The updated platform allows patches, fixes, and new features to be deployed in hours or days, eliminating lengthy release cycles.
• Stronger Security: Compliance, hosting, and security are managed centrally at the AASHTOWare Project platform layer, reducing the burden on individual agencies.
• Consistent Performance: The modernized solution is architected to automatically scale on demand in seconds, providing consistent high performance regardless of load. Peak usage periods no longer mean slowdowns.

Beyond these four benefits, the new architecture improves sustainability and eliminates the accumulation of technical debt that makes AASHTOWare Project increasingly expensive and fragile to maintain over time. In short: modernizing now means moving away from a fragile, costly legacy architecture toward a consistent, sustainable platform, while preserving the workflows your teams rely on every day.

Unlike the move to web-based AASHTOWare Project, this is a replatforming, not a full data migration. Your data remains consistent and in place; the underlying technology and user interface will evolve. The phased approach and hybrid operating model are designed to ensure continuity. The new platform also provides a different risk profile: adjustments can be deployed in hours or days rather than requiring a full release cycle.

No. This is a phased transition. The coexistence phase is specifically designed to allow agencies to operate in a hybrid mode, seamlessly using both the legacy system and the new interface side-by-side for different tasks. No agency will be asked to transition until the new environment for a specific module is fully validated and proven. This will allow for business continuity and operations to continue to deliver for your agencies.

Three steps:

1. Verify your environment: Confirm your agency is hosted and running the latest version of AASHTOWare Project.
2. Prepare for the Customization Cataloging inventory audit: Be ready to partner with the Infotech team for the Customization Cataloging audit. Designate a technical point of contact. Sign up for the Cataloging Audit Calendar at AASHTOWareProject.org to schedule your agency’s Phase 1 session. Agencies should identify their current customization inventory and consider limiting additional customizations where possible during the transition period.
3. Join the feedback loop: Join the feedback loop and actively engage in upcoming sessions, TAG meetings, and office hours. Also, consider joining the User Testing Group to provide early feedback on the new interface and experience.

Your data is protected and remains consistent throughout the entire initiative.

The first phase is a re-platforming, not a data migration, the information you’ve entered, the records you maintain, and the history you’ve built are not being moved from one database to another. The modernized environment is designed to maintain full continuity with your existing data stored in your agency’s data lake.

For the long term, we are modernizing the underlying technical architecture to a more efficient system to ensure the highest levels of performance and security. This evolution of the back end is managed entirely by our team, and your historical data will remain fully accessible to you at all times. The entire process is designed to ensure you never experience a break in service or access to your complete data history.

Your unique ways of working are protected and modernized. Phase 1 includes a detailed review, what we call Customization Cataloging, of all agency-specific customizations, including database triggers and custom code. These unique customizations will be systematically inventoried and assessed to determine their future. The outcome will be to integrate necessary functionality into the supported, standard framework through the Configuration Catalog. This process will replace brittle custom code with supported technical solutions, which could include standardized configuration rules, supported system triggers, or other determined technical solutions, or even obsolescence for underutilized customizations, future-proofing your unique ways of working.

Preserving the business intent of your existing reports and configurations is a core commitment. The process begins with Customization Cataloging to inventory every item. Based on assessment, items will be modernized: some integrated as standard functionality, others updated as supported interfaces, and data-intensive reports may point to your agency’s data lake. The goal is to preserve the unique business outcome, not the legacy code.

This is not a solicitation effort for additional funding. This modernization is funded through your existing license fees to ensure the long-term viability of the AASHTOWare Project platform and your data. Agency costs will primarily be indirect, staff time for participating in the customization cataloging process, user testing, transition efforts, and internal change management, minimized through phased engagement and centralized support. It is also worth recognizing the opportunity cost of not modernizing: the current architecture requires increasing investment to maintain, patch, and support over time. Modernization is the path that frees those resources for the work that matters.

The good news is that your core knowledge and expertise are not going away. The fundamental logic of your work, the “jobs to be done” like adding a project or generating an estimate, will remain the same.

The primary change is the user interface, and we’re treating it as a simplification, not a burden. Most workflows will be streamlined to simplify manual steps and reduce clicks, resulting in a cleaner, more intuitive system. You’ll be interacting with a much more efficient platform, but you’ll be using the same deep knowledge you’ve already built.

To make this transition as smooth as possible, comprehensive training resources, walkthroughs, and support materials will be developed and available for each module prior to its rollout.

The user interface (UI) will be modernized for improved usability, focusing on efficiency, consistency, and automation, an evolution, not a revolution. While the underlying business goals (e.g., adding a project or generating an estimate) remain, the steps will be updated with modern design standards, resulting in cleaner navigation, faster load times, and intuitive layouts. The User Testing Group is being established to ensure these UI changes are sensible for daily users.

While the user interface will change as workflows transition, the core functionalities and “jobs to be done” remain the same. This means any necessary familiarization will not be comparable to learning an entirely new system. Because the transition is phased, training will be delivered workflow-by-workflow, not a single large training event. To support this transition, training resources, walkthroughs, and support materials will be developed for each module prior to its rollout. The phased approach spreads out the training over time, preventing a single, overwhelming training period. Training resources will be available through the Communication Hub at AASHTOWareProject.org.

This is addressed in Section 1. The short answer: preserving the business intent of your reports is a core commitment. Every item is cataloged and assessed. Nothing disappears without a documented plan your agency has reviewed.

The data lake is a modern data infrastructure that will support advanced reporting, analytics, and integrations. For most day-to-day users, access to reports and data will remain familiar. Agencies with sophisticated data analytics needs will have more capability available to them, not less. This is one of the significant long-term benefits of modernization: the time has come to fully realize what advanced data analytics can unlock for your agency’s decision-making.

The hybrid operating model is specifically designed to avoid downtime. During the coexistence phase, legacy systems remain fully operational while new workflows come online alongside them. Module transitions will be incremental to minimize disruption, and agencies will have advance notice of any maintenance windows. If a new workflow requires additional work, the legacy version continues to function, there is no gap in service.

This is where the incremental delivery model provides its most tangible advantage. In the current legacy environment, fixing an issue can require a full release cycle that takes months. In the new delivery model, the team can deploy configuration adjustments and fixes in hours or days. If a workflow isn’t performing correctly after transitioning, the team can respond to your feedback and make corrections in near real time. Additionally, during the coexistence phase, the legacy version of that workflow remains available as a fallback while issues are resolved.

During the coexistence phase, yes. The hybrid operating model means legacy workflows remain available while their evolved counterparts are being rolled out and validated. You can continue using the legacy version for any module that hasn’t been fully transitioned. However, once Phase 3 is complete and all modules have been validated in the new environment, legacy systems will begin to be decommissioned. The goal is to ensure the new version meets or exceeds the legacy experience before that happens, not to force a transition before you’re ready.

Agency views, custom forms built with supported data tables, Python calculation code, custom presentation layouts, and charting capabilities, represent a distinct and significant category of customization, particularly in Construction & Materials. We recognize they are uniquely challenging because they combine custom data structures, custom business logic, custom presentation, and agency-specific reference data in tightly coupled ways that vary substantially across agencies.

The transition path for agency views involves multiple layers of the new architecture: the Configuration Engine for business rules, a managed calculation framework for computation logic, a modern presentation system, and tenant-scoped reference data resolution. The Year 1 customization inventory will specifically catalog agency views as a first-class category to ensure every view has a documented path forward. The business processes those views support will not be abandoned.

Preserving the business intent of your existing reports, saved configurations, and agency-specific business logic is a core commitment of the AASHTOWare Project modernization. The process is designed to ensure that the critical work your agency depends on is not just carried over, but future-proofed in the new environment. Detailed Audit (Phase 1 Cataloging): We begin with a thorough audit, called Customization Cataloging, to systematically inventory and assess the specific nature, purpose, and usage of every report and saved configuration.

Modernization and Integration: Based on this assessment, we will modernize each item to ensure its long-term viability and performance on the new platform:

• Some will be integrated as standard in-app functionality or new, supported configuration rules, replacing older, brittle custom code.
• Others will be updated to become supported interfaces for communication with your other critical agency systems.
• For data-intensive needs, reports may be updated to point directly to your agency’s data lake, providing more flexible and higher-performing access to your information.

Our goal is to preserve the unique business outcome, not the legacy code. Customizations that are underutilized or no longer needed will be thoughtfully assessed for obsolescence in consultation with your agency.

This phased, collaborative approach ensures that we are replacing custom work with supported, standard functionality, preserving your unique workflows while reducing your long-term maintenance burden. You will be fully informed and involved in the transition plan for all your configurations before any changes are made.

We are modernizing the way we deliver updates by moving to frequent, incremental enhancements every two weeks. This ‘sprint’ approach ensures that improvements are smaller, more intuitive, and easier to adopt without disrupting your existing workflows.

You won’t need to go looking for information, it will come to you.In-app guides and notifications will alert you to new features directly within AASHTOWare Project, providing step-by-step walkthroughs as changes go live. For a higher-level view of the project’s evolution, The Hub on AASHTOWareProject.org will host an overall progress roadmap. Additionally, your agency’s designated point of contact will continue to receive regular briefings to ensure your team is always aligned with the broader modernization goals.

Your feedback is actively sought and directly influences the platform’s development. The User Testing Group provides structured opportunities to preview and respond to workflow changes before they’re finalized. Office hours (beginning May 2026) offer direct, open forums for input. The Hub on AASHTOWareProject.org will include a feedback mechanism, either a community forum or structured submission tool, that routes your input directly to the project team. TAG meetings provide monthly, module-specific sessions for detailed technical feedback.

The Communication Hub at AASHTOWareProject.org is your single source of truth. You can submit questions directly through the Hub, access the dynamic FAQ, and sign up for office hours and webinars. Your agency’s end user designee (EUD) is also a direct channel for feedback. For direct contacts, see the Contact section at the bottom of this page.

We want to be unequivocal: agencies’ prior investments in Construction & Materials are not lost. The institutional knowledge, business process decisions, workflow configurations, and data that agencies have built over years of implementation are exactly the inputs that will shape the new workflows. Several specific commitments in the plan address this directly:

• Coexistence phase (Years 2-4): Agencies continue using legacy C&M functionality alongside new workflows. Agencies transition at their own pace, not on a mandated schedule.
• C&M is sequenced last: Construction & Materials is scheduled for Year 3 precisely because it is the most complex module with the deepest agency-specific customization. This gives the Year 1 customization catalog effort time to fully understand the landscape before we build.
• Data continuity is preserved: There is no data migration required. The underlying data remains the same. Each agency will receive a dedicated data warehouse that mirrors the existing data structure, with near-real-time copy-on-write synchronization. Read-based direct database access, which accounts for the majority of agency customization work, will continue to function by simply pointing to a new location.
• Comprehensive Year 1 inventory: A module-by-module inventory with each agency will document every configuration, customization, direct database interaction, and external integration. This is not a cursory survey, the plan includes Infotech staff sitting down with agency teams to capture everything.

Agencies currently in mid-implementation of C&M should continue that work, it strengthens their position for the transition, because a well-understood, well-documented implementation is far easier to transition than one still being defined.

The answer requires distinguishing between types of customization:

• Direct database reads (reports, queries, data extracts): The most common form of agency customization. The data warehouse approach preserves read-based access. Agencies with direct queries will be able to point those queries to the data warehouse with its familiar data structure. A simple connection change should minimize work needed.
• Direct database writes: These will need to transition to supported methods (OpenAPI, system triggers, or Configuration Catalog rules). Direct database writes have never been a supported approach due to data integrity risks, and the updated product provides a supported, clean alternative.
• Custom stored procedures and business logic: These will be evaluated during the Year 1 customization inventory. Many will map to Configuration Catalog capabilities. Others may be addressed through OpenAPI integrations or webhooks. Where a customization reflects a genuine product gap, that becomes a candidate for incorporation into the core product.
• Source code modifications: In a multi-tenant environment, source code customization is not possible. Agencies that customize the source code will need the most planning and the fullest use of the transition support resources.
• Agency views: Custom forms built with supported data tables, Python calculation code, and charting capabilities represent the most complex category. The transition path involves multiple layers of the new architecture (Configuration Engine, managed calculation framework, presentation system, and tenant-scoped reference data resolution). Agency views will be cataloged as a first-class category in the Year 1 inventory.

The Year 1 inventory is specifically designed to identify every customization, understand its business purpose, and map a path forward, whether that is core product incorporation, Configuration Catalog support, OpenAPI integration, or assisted transition services. C&M is sequenced for Year 3 specifically to give the Year 1 inventory and Year 2 Configuration Catalog development time to be ready for the most complex module.

The nature of some customizations will change in the new environment, and it is important to be precise about what that means:

• Customizations absorbed into the core product: Where the Year 1 customization catalog reveals that multiple agencies have implemented similar customizations (the “80” of the 80/20), those capabilities will be built into the core product at no additional agency cost. This is a net gain, agencies get a supported, upgradeable version of functionality they previously maintained independently.
• Customizations addressed by the Configuration Engine: Some agency-specific configurations will be supportable through the new Configuration Engine’s rules and templates without being unique product features. Agencies will configure these using supported tools rather than custom code. This is also included in the fixed-price scope.
• True outlier customizations: For customizations that fall in the “20”, unique to a single agency and not candidates for core product incorporation, some services may be available via Service Units or work orders. These would be new work in the new platform, not a duplication of previous charges. The Year 1 inventory is designed to quantify and communicate this exposure clearly before agencies face any financial decisions.

We acknowledge that the project exclusion related to “agency-specific configuration or customization development” introduces uncertainty. Here is the specific breakdown:

Included in the fixed-price scope (no additional agency cost):

• Core product configuration: The Configuration Engine (Track 3) will support agency-specific business rules, field-level behaviors, calculation logic, workflow routing, and approval chains through a standardized, supportable framework.
• Customization inventory and assessment: The comprehensive module-by-module inventory of every agency’s configurations, customizations, database interactions, and integrations, including the analysis that determines what falls into the “80” vs. the “20.”
• Commonly-used customizations absorbed into core: Customizations that the inventory reveals are widely used across agencies will be built into the core product.
• Data warehouse and API infrastructure: The Snowflake-based per-agency data warehouse, OpenAPI framework, and webhook/integration capabilities that provide the supported extensibility layer.
• Agency transition support: Up to 2 months of 3 FTEs per agency, focused on out-of-the-box functionality and transition planning.

Excluded from the fixed-price scope (may involve agency cost):

• Truly unique, single-agency customizations: If an agency has a configuration or business process that is genuinely unique, not shared by other agencies, not a product gap, and cannot be met through the Configuration Engine, data warehouse, or OpenAPI framework, then implementing that capability may be an agency-funded effort through Service Units or work orders.
• Custom integrations with third-party systems not identified in the program: The project provides the API and integration framework, but building the specific connection to an agency’s unique external system (e.g., a state-specific financial management system) would be agency-funded or pursued through future enhancement requests.

How these determinations will be made:

The decision process is collaborative and transparent, not unilateral. It follows four steps: (1) Inventory, Infotech conducts the comprehensive customization catalog with each agency, by module. (2) Analysis and classification, each customization is assessed against criteria including how many agencies use it, whether it represents a product gap, and whether it can be addressed through existing tools. (3) PTF review and input, the analysis and proposed classification will be shared with the PTF, which has governance authority over borderline cases. (4) Transparent communication, before any agency faces a financial decision about an excluded customization, they will have clear information about what it is, why it falls outside scope, what alternatives exist, and the estimated cost.

The transition will change some of the mechanics of how outcomes are achieved and will require adaptations. In the new environment, many issues that currently require a custom agency solution or a Ticketed Modification Request and a release cycle can be addressed through configuration changes deployed in near real time. Infotech remains committed to agency needs and as the modernization project progresses, Infotech and agencies will assess current services work to determine any impacts and adjust accordingly. The multi-year phased approach of this project means that there will be no immediate impact to current services engagements. Additionally, Infotech will evolve services offered to include new or expanded offerings to help agencies get the most of the new solution.

Here is how TMRs will be handled: For Modules Not Yet Transitioned: The ability to enhance, maintain, and support modules that have not yet moved to the new platform remains in place. They are still eligible for modification and TMR processing within the current system, ensuring no loss of service or improvement capacity during the transition. For Transitioned Modules:

Once a module has successfully transitioned, the focus of modification and enhancement efforts will naturally shift to the new platform. This is a positive change, as the new model allows us to address many issues that currently require a formal TMR by delivering faster configuration changes, often in hours or days instead of weeks or months.

In short, your enhancement and maintenance needs will continue to be met, and the long-term goal is a platform that makes future support and enhancements even faster and more responsive.

In general terms, yes, earlier engagement provides advantages, though the plan is designed to ensure that no agency is penalized for transitioning later in the program. The dedicated transition support resources (up to 2 months of 3 FTEs per agency, focused on out-of-the-box functionality) are available at any point during the five-year plan, regardless of when an agency chooses to transition. That said, there are benefits to earlier engagement:

• Greater influence over product direction. Agencies that participate in early workflow discovery and testing cycles have more opportunity to shape how the transformed product is designed. Feedback from early adopters directly informs how subsequent modules are built.
• Longer runway for customization planning. Agencies with complex customizations, particularly agency views, Python calculation code, or direct database write operations, benefit from engaging with the Year 1 customization catalog process as early as possible.
• Earlier access to platform improvements. Once an agency transitions to the new environment, they immediately begin receiving the benefits of continuous delivery, rapid feature releases, simultaneous updates, and a modern user experience.
• Reduced organizational change burden. Agencies that transition earlier encounter a smaller delta between the legacy and modern experience. Agencies that wait until later face a larger cumulative change, which can increase the internal change management effort required.

The coexistence model ensures that agencies are not forced to cut over before new workflows are validated. Legacy module support is maintained throughout the coexistence phase (Years 2-5), and the legacy product remains functional and supported during this period.

Our goal is to prevent a full module failure through our “no forced cutover” principle and our incremental, workflow-by-workflow rollout. Because we expose and test each workflow with users before transitioning the full module, we believe we will address and fix issues in real-time, long before they can aggregate into a major failure. However, if a workflow in the new environment is not meeting your needs during the Phase 2 parallel operation, here is our commitment:

• Immediate Fallback: The legacy version of that workflow remains fully operational and available for your use, there is no service gap.
• Rapid Remediation: The new model allows us to pause the transition for that specific workflow and deploy configuration adjustments and fixes in hours or days, not weeks or months.
• PTF Oversight: The issue is immediately surfaced through PTF feedback loops or TAG meetings, and a remediation plan is developed and shared with affected agencies.

The key takeaway is this: The module does not proceed to full transition until the issue is resolved and validated with users. We will always operate with the utmost transparency and with your feedback informing the decision to pause or proceed.

The primary preparation step is ensuring your agency is currently hosted and running the latest version of AWP. This is the baseline compatibility requirement. In the new model, hosting, patching, security updates, and infrastructure maintenance shift from the agency to the platform, which should reduce, not increase, the burden on your internal IT team over time. For agencies that are not currently hosted, a path to hosted status will need to be established before their modules can transition. If your agency has specific infrastructure concerns or constraints, raise them through the PTF feedback loop or directly with the initiative team so they can be addressed during Phase 1 planning.

If your agency has staff dedicated to maintaining, building, or supporting AWP customizations, their roles will evolve as the transition progresses. In Phase 1, these team members are valuable partners in the cataloging audit, they understand your customizations better than anyone. In Phases 2 and 3, as customizations are transitioned to supported functionality, the maintenance burden on internal teams decreases. This doesn’t necessarily mean those roles disappear, it may mean they shift from maintaining legacy customizations to participating in the User Testing Group, providing feedback on new configurations, or focusing on other agency technology priorities.

The five-year timeline is a planning framework, not a hard deadline after which the initiative stops. If specific modules or agencies require additional time, the phased approach accommodates that, modules transition when they’re ready, not when an arbitrary date arrives. The legacy system will not be decommissioned until all modules have been successfully transitioned.

That said, we must ultimately reduce the burden of maintaining two platforms. The PTF will thoughtfully consider agency status, support costs, and other strategic factors before setting a final sunset date for the web-based product. After this date, the legacy product will be decommissioned in line with the process defined in the AASHTOWare Standards and Guidelines.

The monthly Progress vs. Pivot reporting will provide transparent visibility into whether the initiative is tracking ahead or behind, ensuring the PTF has all the necessary information to make this decision collaboratively.

The Hub on AASHTOWareProject.org will include a Resource Pack designed specifically for internal communication, a high-level visual roadmap, the FAQ, and key talking points that agency leadership can share with their executive sponsors, IT leadership, and end-user teams. The core message should be: The AASHTOWare Project Modernization is a Strategic, Funded Investment, Not a Disruption.

Key Talking Points:

• Cost Neutrality: This is a zero-additional-solicitation-funding initiative. It is a long-term investment funded through existing license fees, ensuring the 10-20 year viability of the platform.
• Minimal Agency Disruption: This is a phased evolution, not a disruptive, one-time cutover. It is not a repeat of the previous migration experience.
• Support and Partnership: We preserve existing workflows and are committed to minimizing the burden on your team. This includes providing up to 2 months of dedicated, hands-on support by 3 FTEs per agency to assist with the transition of out-of-the-box functionality.
• Strategic Benefits: The initiative reduces long-term maintenance burden, improves the platform’s security, and enhances usability for your staff.

The modernization is a platform-wide initiative, all agencies will eventually transition to the new environment. However, the phased approach means agencies are not all transitioning at the same time. The sequencing accounts for agency readiness and complexity. If your agency has specific timing constraints, for example, a major internal initiative that would conflict with active participation in the cataloging audit, raise those concerns through the PTF feedback loop so they can be factored into the scheduling. The initiative team is committed to working with agencies, not imposing arbitrary deadlines on them.

Monthly progress vs. pivot reports will be published to the Hub and shared with PTF. These reports are not marketing, they reflect honest status against milestones, and will flag pivots transparently when plans change. The goal is a communication posture that builds credibility through consistency, not polish.

The move to a cloud-native platform fundamentally changes what is possible with your agency’s data. Today, data is often locked in legacy structures that are difficult to access for reporting and analysis. The modernized platform introduces a data lake architecture that makes your agency’s data available for real-time reporting, advanced analytics, and integrations with other state systems.

Yes. One of the core principles of the modernization is that your data belongs to your agency. The data lake gives agencies direct, structured access to their data in formats that support modern analytics tools, dashboards, and integrations, without requiring workarounds or custom extracts.

Agencies will be able to build real-time dashboards, automate reporting workflows, integrate AASHTOWare Project data with other state transportation and financial systems, and leverage modern BI tools. Data-intensive reports that currently run slowly on the legacy platform will be served from the data lake for faster, more reliable results.

Each agency will receive a dedicated data warehouse that mirrors the existing data structure, with near-real-time copy-on-write synchronization. Read-based direct database access, which accounts for the majority of agency customization work, will continue to function by simply pointing to a new location. Limited re-writing of read queries is expected; a simple connection change should minimize work needed.

For agencies with direct database write operations, those interactions will need to transition to supported methods, OpenAPI, system triggers, or Configuration Catalog rules. Direct database writes have never been a supported approach due to data integrity risks, and the modernized product provides a supported, clean alternative. The Year 1 inventory will identify all such interactions and develop a specific transition plan for each agency.