SCRT_SourcesSought-Mar2026-Final.pdf

NOTICE of SOURCES SOUGHT SCRT Technical Refresh

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

Information received from this notice will not be disclosed outside the government.

The Defense Finance and Accounting Service (DFAS), Contract Services Directorate, is seeking sources and capability statements on market capabilities for a System Integrator that has proven experience leading large-scale government application technical refresh efforts. All qualified and experienced sources including small businesses, 8(a) small businesses, service-disabled veteran-owned small businesses, HUBZone small businesses, and Women-owned small businesses are encouraged to respond to the Notice.

This Sources Sought is to gather information on capabilities and solutions for technically refreshing a legacy PowerBuilder application. It is driven by a strategic initiative to technically refresh our legacy applications to better support our mission. The current Standard Contract Reconciliation Tool (SCRT) is a critical component of our operations, but its underlying technology limits our ability to adapt and scale.

The primary drivers for this technical refresh effort are:

Cloud Transition: We are pursuing a strategic migration from on-premises, client-server architectures to modern, cloud-native solutions to enhance scalability, reliability, and security.

Enhanced Security: The future solution must natively support current DoW security mandates, including the ability to enable critical CAC/PKI authentication for all users.

Future Adaptability: The technically refreshed platform must be extensible and more adaptable to changing business needs, allowing for more rapid integration of new processes and data sources without requiring major redevelopment efforts.

1.0 DESCRIPTION OF REQUIREMENTS & DESIRED CAPABILITIES

1.1 System Description

SCRT is a comprehensive, client-server application developed in PowerBuilder that utilizes an Oracle database. Its primary function is to automate and streamline the contract reconciliation process. As a

Windows-based application, SCRT provides a graphical user interface for data access and updates. The system is engineered to ingest and format data from external partners, serving as a centralized hub that facilitates team collaboration on reconciliation tasks and prevents duplicative work.

SCRT is composed of several key modules that collectively provide a powerful reconciliation capability:

Registration: This component enables users to register new contracts, query the status of existing ones, manage team member assignments, and oversee the contract reconciliation iterations associated with each registration.

Compare: The Compare module performs automated data comparisons between data from different systems, proactively alerting users to discrepancies or other adverse data conditions. It also provides users with configurable controls to define the parameters of the comparison logic.

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

Adjustments: This module allows authorized users to apply necessary adjustments to data following the Compare process. To ensure full accountability, every approval is tracked to the user responsible.

Reports: The Reports component provides users with access to critical data for research and supporting documentation. The system can generate both standard operational and management-level reports, which can be viewed directly on-screen or printed.

The following section outlines the functional, technical, and compliance requirements for the SCRT technical refresh effort. The vendor will be responsible for a complete, end-to-end technical refresh of the application, from development and testing to integration and deployment, while adhering to all specified standards.

1.2 Functional Requirements

The primary functional objective is to transition the application to a modern framework while preserving its core business value and user experience.

Functional Parity: The technically refreshed solution must recreate all screens, workflows, and business logic of the current PowerBuilder application. The goal is to achieve a "like-for-like" functional replacement.

User Experience (UX): The new system must maintain the current level of usability. Screen layouts, data entry fields, and input validation checks should appear and function in a manner consistent with the existing application to minimize the need for extensive user retraining for daily operations.

1.3 Technical Requirements

The technically refreshed system must be built on a sustainable, secure, and extensible technology stack.

Architecture: The solution must be based on a non-proprietary, object-oriented codebase. The use of low-code/no-code platforms is strictly prohibited.

Database Integration: The technically refreshed application must integrate with the existing

Oracle 19c database. This includes leveraging existing database functionality (e.g., stored procedures, functions) where possible. The vendor will be responsible for modifying database objects as necessary to ensure effective and performant integration with the new application framework.

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

Development and Operations (DevSecOps): The vendor must establish and utilize a robust

DevSecOps pipeline. This pipeline will use GitLab for source control and CI/CD, integrate

Fortify (or equivalent) for static code analysis, and include a comprehensive automated test suite to enable regression testing for all future modifications. The vendor will be responsible for delivering automated test scripts.

Grant of Unlimited Rights: Pursuant to DFARS 252.227-7014, the Contractor will grant the

Government unlimited rights in the resulting refreshed source code and functional application.

The Contractor will relinquish any and all claims to the intellectual property of the resulting source code and functional application delivered under this contract and will agree that it shall have no claim against the Government for the use, modification, reproduction, release, performance, display, or disclosure of such computer software.

1.4 Security and Compliance

The solution must comply with all applicable DoD and DFAS security mandates from its inception.

General Compliance: All software, whether commercial-off-the-shelf or custom-developed, must fully comply with all relevant DoD and DFAS cybersecurity guidelines, including but not limited to: Zero Trust Architecture, DISA Security Technical Implementation Guides (STIGs), NIST Special Publications, DoD Risk Management Framework, SSAE18, and the DoD Financial

Management Regulation (FMR).

Identity, Credential, and Access Management (ICAM): The solution must provide critical

CAC/PKI authentication, fully integrated with DISA’s Enterprise-ICAM solution. It must enforce

Role-Based Access Control (RBAC).

Vulnerability Management: All code and components must be scanned for vulnerabilities using government-approved tools like Fortify or the Assured Compliance Assessment Solution

(ACAS). All findings must be tracked in a vulnerability tracker, and a Plan of Action and

Milestones (POAM) must be maintained for remediation.

Supply Chain Security: All tools, platforms, and software libraries must be clearly identified with their company and country of origin to comply with supply chain risk management requirements. All software must be on currently supported versions with a clear path for patch management.

Information Handling: The system must be capable of handling and protecting Controlled

Unclassified Information (CUI) in accordance with DoD Instruction 5200.48.

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

Internal Controls: The system must implement controls compliant with the Risk Management

Framework (RMF) and the Federal Information System Controls Audit Manual (FISCAM), with a focus on providing automated internal compliance checks.

Section 508: The solution must be fully compliant with the applicable accessibility standards outlined in 36 CFR 1194.

1.5 Performance and Stability

The technically refreshed system must meet or exceed the performance and reliability of the current application.

Performance: The system's processing times for key transactions and operations must be comparable to those of the existing system.

Uptime and Stability: The solution must be engineered to achieve an average uptime of 99.5% or greater annually.

Data Integrity and Quality: The system must perform all calculations, summations, and account balancing with the same level of accuracy as the original system. The vendor will be required to participate in parallel testing to validate data integrity, and any identified discrepancies must be rectified immediately.

2.0 Current System Environment

The SCRT is a mature client-server application with a recently updated hosting environment. The technical details of the existing system are as follows:

Application Framework: The front-end application is built using PowerBuilder Version 2019

R3.

Database: The back-end database is Oracle 19c.

Operating System: The application servers run Red Hat Enterprise Linux (RHEL) Version 8, hosted in DISA's Stratus Cloud environment.

User Base: The system currently supports approximately 390 end users. These users consist of

DFAS personnel and other DoD components involved in contract reconciliation, adjustments, and reporting.

Key Integrations: SCRT is not a standalone system; it interfaces with 14 key DoD financial and administrative systems to perform its function.

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

The following table provides a high-level summary of the object counts within the current SCRT

PowerBuilder application source code. This is intended to give vendors an approximation of the application's size and complexity.

Object Type File Extension Count

Applications .sra 1

DataWindows .srd 786

Functions .srf 66

Menus .srm 60

Structures .srs 54

User Objects .sru 480

Windows .srw 299

Total Objects 1,746

DFAS seeks to partner with a System Integrator that has proven experience leading large-scale government application technical refresh efforts. The ideal vendor will demonstrate expertise in integrating the diverse technical, security, and functional aspects required to deliver an efficient, stable, and secure modern system.

The capability statement should include the following:

A description of the proposed solution, including the following:

Technology stack and technical approach

Security and compliance

A project plan with a detailed timeline.

A cost breakdown.

Recent and relevant contracts (last 3 years), including the

Contract number and order number (if applicable)

Dollar value

Period of performance, Point of Contact information, and

Scope of work.

The government has very specific questions vendors must address in their responses:

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

1. In the event this effort results in a requirement, will your company submit a quote in the event a solicitation is received?

2. PowerBuilder Technical Refresh Experience: Describe your firm's experience technically refreshing applications written in PowerBuilder to a modern, object-oriented language. Please specify your approach to handling legacy PowerBuilder frameworks, if applicable.

3. High-Level Technical Refresh Approach: Based on the project overview, what is your recommended high-level approach (e.g., automated code conversion, manual rewrite, re-architecture, hybrid model)? Justify your recommendation.

4. Proposed Technology Stack: What modern technology stack(s) do you propose for the technically refreshed system? Provide a clear rationale for your choices, considering performance, scalability, security, long-term maintainability, and alignment with DoD standards.

5. DoD Security and ICAM Integration: Provide specific examples of projects where you have successfully obtained an Authority to Operate (ATO) under RMF, complied with DISA STIGs, and integrated with DoD CAC/PKI for authentication. Describe how your proposed solution will integrate with DISA’s Enterprise-ICAM solution.

6. Capabilities Alignment: For each of the capabilities listed above, provide a detailed description of how your solution meets the requirement.

7. Technical Details: Describe the hosting options for your solution, detail your solution's ability to be deployed and sustained in a secure environment, describe the integration capabilities of your platform (e.g., APIs, supported tools).

8. System Interfaces: Describe the methodology and discovery process you would use to analyze, document, and re-implement the 14 key system interfaces. How would you approach testing and validating these integrations in the new environment?

9. Assumptions: Please list the assumptions your firm is making regarding Government Furnished Information and access, including but not limited to: access to the existing PowerBuilder source code, access to subject matter experts (SMEs), and availability of test environments for integrated systems.

10. Disaster Recovery: Describe your approach to disaster recovery and business continuity. What are the typical Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for the architecture you are proposing?

11. Timeline: Provide a typical implementation timeline for a large enterprise.

12. Training and Support: Describe your training and customer support models.

13. Rough Order of Magnitude (ROM) Pricing: Provide a non-binding ROM for your solution.

Please describe your licensing model (e.g., per user, per system, enterprise).

Disclaimer: This request for information is for market research purposes only. This is not a solicitation.

Please respond to the contact listed below with no more than eight (8) pages explaining in detail the magnitude of your experience in the above-mentioned subject matter area.

Qualified sources should submit their response via email to chrissy.j.webb.civ@mail.mil by March 31, 2026, at 12PM ET. Questions should be submitted no later than March 23, 2026, at 12PM ET.

Sources should include their business address, point of contact, cage code, Unique Entity Identifier (UEI) number and small business status (for example, HubZone or Service-Disabled Veteran Owned).