Test-certified migration for enterprise SAS code bases
Your SAS estate works. Thousands of programs, macros, formats and scheduled jobs have been refined over years, and much of what they do is documented nowhere but in the code itself. Moving that to any new platform, however compatible, carries one real risk: something that used to be right is now subtly wrong, and nobody notices until it matters.
Jenner Professional Services removes that risk with a simple discipline. Before we change anything, we build a comprehensive, executable record of what your current system does. Then we use that record to prove, test by test, that the migrated system does the same.
The result is a migration you can sign off on with evidence rather than confidence, and a regression suite you keep forever.
We are experts in SAS, as demonstrated by having created a complete implementation of that language and system. However, migrating to that system is just one of the paths you can take with us.
We can use our implementation of SAS-compatible code, and our test-driven practices, to ensure a successful migration to Python, or R, to Snowflake, or Databricks, or other solutions — even Siemens SLC.
We advocate migration to Jenner because it is both faster, less complex and lower cost for businesses that have an existing SAS infrastructure.
Jenner runs the SAS language, almost every procedure, the macro facility, graphics and a wide range of data connections. For most code, migration is a matter of pointing Jenner at the same programs. But an enterprise code base is never just the language. It is also everything the language touches:
autoexec.sas, config files, system options (ENCODING, LOCALE, YEARCUTOFF, VALIDVARNAME, FMTSEARCH, SASAUTOS), environment variables, SYSPARM, and the WORK library's size and lifetime.
Passwords embedded in LIBNAME statements, {SAS002}-encoded strings, credentials in %included files, Kerberos or SSO tickets, and the question of where all of that should live instead.
SAS/ACCESS engines for Oracle, DB2, Teradata, SQL Server, Snowflake, Hive and others; explicit and implicit pass-through SQL; engine options that affect results (DBCOMMIT, READBUFF, INSERTBUFF, BULKLOAD); type mapping for dates, decimals and NULLs; and behavior that quietly changed when SQL was pushed down to the database rather than executed locally.
Hard-coded paths, Windows drive letters versus Linux mounts, case-sensitive filenames, NFS and SMB shares, FILENAME PIPE and X commands, SYSGET, and file permissions.
Format catalogs, compiled or stored macros, indexes, audit trails, views, SPDE libraries, transport files, encrypted or compressed datasets, and V6/V8-era datasets that need regeneration rather than copying.
SAS/CONNECT RSUBMIT blocks, Grid, SAS/SHARE, Stored Processes, metadata-server authorization, Enterprise Guide projects, DI Studio-generated jobs, and Viya CAS actions. Each has an equivalent on the new platform, but not an identical one.
LSF, Control-M, cron, job dependencies, return-code conventions, log scrapers that look for specific NOTE/WARNING/ERROR text, SYSERR and SYSCC logic, and FILENAME EMAIL alerts.
ODS PDF, RTF, Excel and HTML destinations, PROC TEMPLATE styles, tagsets, fonts, graph device drivers, and reports that downstream consumers parse by position.
Floating-point rounding at boundaries, sort collation and tie order, random number streams (RANUNI, RAND, STREAMINIT) that are not reproducible across implementations, and iterative procedures whose convergence path can differ within tolerance.
Uninitialized variables, PROC SQL remerging, implicit RETAIN, truncation warnings treated as normal, and undocumented behavior that happens to produce the right answer today.
Python via SASPy, R, Java and .NET clients over IOM, JDBC to SAS/SHARE, Tableau and pandas reading .sas7bdat files directly, and REST calls into Viya.
Validation requirements in regulated industries (GxP, 21 CFR Part 11, model risk management), row-level security, PII handling, audit trails, and the absence of version control in many long-lived SAS estates.
None of these is unusual. All of them are findable in advance, and all of them are testable. That is the point of the process below.
We inventory the estate before estimating the work. Using automated analysis of your source tree, schedules and logs, we produce a dependency graph of programs, macros, formats, libraries, external files and database connections, and identify what is actually run, what is dead, and what is owned by whom. Every category above is checked and the findings are scored by migration effort.
An inventory and risk report with a fixed-price proposal for the remaining phases. If you decide not to proceed, you keep the report.
This is the phase that makes the rest reliable, and it is done entirely on your existing SAS system, before anything is migrated.
For every program in scope, we use AI-assisted analysis to build characterization tests: executable specifications of what the code does today. Each test captures the inputs a program consumes — datasets, macro parameters, external files, database extracts, environment settings — runs it on your current SAS installation, and records everything it produces: output datasets, log contents, return codes, ODS output, macro variable state, and side effects such as files written or emails sent.
AI is what makes this practical at enterprise scale. Reading ten thousand programs and inferring the edge cases each one handles is not a job for people with a deadline. Generating the test cases, the fixtures and the comparison logic is exactly the kind of high-volume, pattern-heavy work at which current models excel, and every generated test is validated by running it against the system it describes. If a test does not pass on your current SAS, it is not a test of your system and it is discarded.
Comparison rules are set per output. Datasets compare exactly by default; numeric tolerances are declared explicitly where floating-point or iterative procedures make bit-for-bit equality meaningless; log comparisons are structural rather than textual, so a reworded NOTE does not fail a job while a changed row count does. Non-deterministic inputs such as the current date and random seeds are controlled so the same test gives the same answer on any day. Where production data cannot be used for testing, we build masked or synthetic fixtures that exercise the same code paths.
A version-controlled test suite with measured coverage across programs, macros and procedures, and a baseline of recorded results from your current system. This suite is yours. It is written to run on Jenner, on SAS, and on anything else that speaks the language, and it is valuable independent of the migration: most SAS estates have never had one.
With the baseline in place, migration becomes an engineering exercise with a clear definition of done. We stand up Jenner in your environment, remediate the environmental items found in Discovery (paths, libraries, secrets management, database connections, scheduler integration), and run the full suite.
Every failure is triaged into one of four categories:
The code is correct and Jenner is wrong. Jenner ships new builds weekly; defects found in customer migrations are prioritized, and the failing test becomes a permanent part of Jenner's own regression suite.
A path, credential, connection or option that needs to be set. Fixed and re-run.
The code relies on undocumented SAS behavior. We show you the specific line and the specific behavior, and you choose between changing the code — with the test proving the change is safe — or Jenner matching the quirk.
The result differs within a declared tolerance, or a log message is worded differently. Documented and signed off, never silently accepted.
The suite is run continuously as issues are fixed, so progress is a number, not an opinion, and regressions are caught the same day they are introduced.
A migrated code base with the full suite passing, or every remaining difference dispositioned in writing.
Certification is the evidence package that lets your sponsor, your auditors and your regulators accept the migration.
We run a parallel period in which production jobs execute on both systems and outputs are compared automatically using the same rules as the test suite. The certification package includes the inventory, the test suite and its coverage, the baseline, the final run results, the disposition of every difference, and the traceability from each requirement or program to the tests that cover it. For regulated customers this is structured to support IQ/OQ/PQ validation and audit.
A signed certification package and a go/no-go recommendation.
Cutover is planned around your batch windows and your SAS license renewal date, with a tested rollback path. Schedulers are repointed, monitoring and alerting are confirmed, and the SAS environment is retired on your timetable.
The test suite continues to run after cutover. Because Jenner ships weekly, you get every improvement with the same proof that nothing you depend on has changed. Your team is trained to extend the suite as the code base grows.
Production on Jenner, a retirement plan for SAS, and a regression suite that keeps working for you.
Fixed-price and short. It produces the proposal for the remaining phases, priced on the measured size and complexity of your estate rather than on an estimate of it.
Typically delivered as a single fixed-scope engagement, with milestone acceptance tied to suite results.
Available as an annual service, after the test suite has been handed over and your team trained to extend it.
$1,000 – $21,000
Can typically be performed remotely, ranging in time from a week to a month.
$52,000 – $405,000
Requiring some onsite work and/or advanced domain expertise, typically ranging from two months to six months.
All amounts are in US dollars (USD).
This does not include software license fees, however these are very straightforward and competitive. See the pricing page.
Contact Professional ServicesSend us a description of your SAS environment — platform, approximate program count, products in use, databases and schedulers — and we will scope a Discovery engagement.