SBA’s Proposed Size Standard Overhaul Could Reshape the Federal Small Business Market

By Brian Kolbay Newsletter Archives August 20, 2026

TAKE NOTE (Insights and Emerging Technology)

The U.S. Small Business Administration has proposed a major overhaul of how it determines which companies qualify as small businesses for federal contracting…

Published in the Federal Register on August 20, 2026, the proposal would significantly restructure SBA’s size standards and could expand the number of companies eligible to compete for small-business set-asides. For federal contractors in information technology, engineering, and professional services, the potential impact is substantial.

Several of the NAICS codes most affected by the proposal are among the most widely used in federal technology and professional-services contracting. SBA estimates that thousands of companies with existing federal contracts could newly qualify as small businesses, including 5,314 firms under NAICS 541330 Engineering Services, 2,247 under 541519 Other Computer Related Services, 2,171 under 541511 Custom Computer Programming Services, 1,818 under 541611 Administrative and General Management Consulting Services, and 1,663 under 541512 Computer Systems Design Services. For companies already competing as small businesses in these markets, that could mean a considerably larger and more experienced competitive field.

The proposal presents both an opportunity and a challenge. On the positive side, growing small businesses could remain eligible for federal small-business programs longer, reducing the so-called “graduation cliff” that can force a successful contractor into full-and-open competition before it has developed the scale, past performance, and infrastructure of much larger federal integrators. The expanded standards could also give contracting officers a larger pool of capable small businesses, potentially supporting additional set-aside opportunities.

At the same time, existing small businesses could find themselves competing against larger and more mature firms that previously exceeded SBA’s size limits. Those companies may bring deeper prime contract past performance, larger recruiting and proposal organizations, stronger customer relationships, and greater pricing flexibility. This makes socioeconomic programs such as WOSB, SDVOSB, HUBZone, and 8(a) potentially even more important as competitive differentiators if the general small-business pool becomes substantially larger.

The rule is still only a proposal, and its final form could change following public comment. Comments are due September 21, 2026. Federal contractors should nevertheless begin evaluating how the proposed standards could affect their competitive landscape, growth strategy, NAICS portfolio, and approach to small-business and socioeconomic set-aside opportunities. For many firms in the federal IT and professional-services market, this could represent one of the more consequential changes to small-business competition in years

Read original at Federal Register link below

UNDER DEVELOPMENT (Insights for Developers)

Migrating from SAP Process Orchestration to SAP Integration Suite

Intro

Migrating from SAP Process Orchestration to SAP Integration Suite can be a challenge. For many large SAP environments, SAP Process Integration and SAP Process Orchestration have served as the connective tissue of the enterprise for years.

PO often sits between SAP ERP and dozens, sometimes hundreds, of external systems. It handles IDocs, files, web services, databases, supplier connections, custom applications, legacy systems, and business-to-business transactions that the organization depends on every day.

Yet despite billions of dollars invested in cloud migration initiatives, many organizations discover that moving SAP to the cloud does not automatically deliver the business transformation they expected.

That history is exactly what makes migrating from SAP Process Orchestration to SAP Integration Suite more complicated than simply replacing one integration platform with another.

The technical migration matters, but the larger opportunity is architectural.

Organizations already moving toward SAP S/4HANA, cloud applications, SAP Business Technology Platform, API-driven integration, and increasingly event-driven architectures should not carry every legacy integration decision into the new environment. The right objective is not simply to move SAP PO to the cloud. It is to use the transition from SAP PO to establish a simpler, more standardized, and more adaptable integration architecture. That distinction should drive the entire migration strategy.

SAP PO MIGRATION IS PART OF A LARGER MODERNIZATION JOURNEY

SAP Process Orchestration 7.5 remains under mainstream maintenance through the end of 2027, with optional extended maintenance available through 2030. Those dates understandably create urgency, but approaching the initiative purely as an end-of-support project can lead organizations directly into the wrong migration strategy.

A deadline-driven program tends to focus on interface counts, conversion schedules, staffing requirements, and the date PO can finally be turned off. Those are necessary questions, but they are not sufficient.

A modernization program goes further. It asks whether every existing integration still needs to exist, whether certain point-to-point connections should be eliminated, whether some services should become governed APIs, whether synchronous interfaces should become event-driven, and whether custom mappings or integrations can be consolidated into reusable patterns.

That changes the outcome dramatically. One approach replaces the middleware platform while preserving most of the legacy architecture. The other uses the migration as an opportunity to simplify the integration landscape itself.

EVERY INTEGRATION SHOULD FACE A DELIBERATE DECISION

Once the landscape is understood, organizations should resist the temptation to assume that every PO object belongs in Integration Suite.

Instead, every integration should effectively face one of four decisions: retire it, migrate it, refactor it, or modernize it.

Some interfaces should simply be retired. If the underlying application, process, or business requirement is disappearing, there is little value in recreating the interface in a new platform. Every interface eliminated before migration is one that never has to be redesigned, built, tested, secured, monitored, or maintained again.

Other integrations are structurally sound and can be migrated with relatively limited redesign. Cloud Integration supports many of the traditional application integration patterns historically handled through PI and PO, and SAP provides tooling that can accelerate the migration of supported artifacts and scenarios.

A third group…

Q&A (Post your questions and get the answers you need)

Q. I am guessing you just watched the above video, and you are asking yourself… that’s great, but why use SAP accelerators for PO to BTP Integration Suite migration? What are the advantages?

A. OK for starters, SAP accelerators provide a structured way to inventory, classify, migrate, modernize, and test what already exists in SAP Process Orchestration. That structure is important because most organizations are not starting with a clean integration landscape. They may have hundreds or thousands of interfaces developed over many years, with varying levels of complexity, customization, documentation, and business criticality

The first advantage is automated assessment instead of manual discovery. SAP’s Migration Assessment capability can analyze existing PO integration scenarios and help determine migration feasibility, complexity, dependencies, potential issues, and estimated technical effort. This allows organizations to quickly separate interfaces that can move largely as-is from those that need refactoring, redesign, or retirement.

The second advantage is reuse instead of rebuilding. SAP’s Business Accelerator Hub provides pre-delivered APIs, integration packages, templates, and other reusable content. Before recreating an existing PO integration, teams can determine whether SAP already provides a supported integration pattern that meets the requirement. This can reduce custom development, shorten migration timelines, and lower long-term maintenance costs.

Accelerators also enable automated conversion where appropriate. Supported PO scenarios can be converted into Integration Suite integration flows rather than manually recreating every mapping, routing rule, adapter configuration, and integration object. The goal is not to automate everything, but to automate the repeatable portions of the migration so skilled integration resources can focus on the more complex scenarios.

Perhaps most importantly, accelerators support modernization rather than a simple lift-and-shift. A PO-to-BTP migration is an opportunity to reassess whether existing integrations still represent the best architectural approach. Interfaces can be evaluated against newer patterns such as API-first integration, event-driven architecture, and cloud-native integration services. Obsolete interfaces can be retired, redundant integrations consolidated, and heavily customized interfaces redesigned where there is a clear business or technical benefit.

Finally, accelerators help reduce testing and transition risk. PO interfaces often support mission-critical business processes, so simply confirming that an interface deploys successfully is not enough. Automated and regression testing can help compare existing PO behavior with the new Integration Suite implementation, giving organizations greater confidence that the migrated integration performs as expected before production cutover.

The result is a migration approach that is more systematic and repeatable. Instead of treating every PO interface as a separate development project, organizations can use accelerators to determine what to reuse, automate, refactor, redesign, retire, and test, helping reduce migration effort while creating a more modern and maintainable integration landscape.

Cheers!