SQL Server modernization workflow

This section provides a step-by-step walkthrough of the complete SQL Server modernization process using AWS Transform.

Step 1: Create SQL Server modernization job

Begin your modernization journey by creating a new transformation job in the AWS Transform console.

1. Sign in to the AWS Transform console

2. Choose Create modernization job

3. Select Windows modernization job and then select SQL Server modernization

4. Enter job details:

   • Job name: Descriptive name for your project

   • Description: Optional description

   • Target region: AWS region for deployment

5. Choose Create job

   Important

   Do not include personally identifiable information (PII) in your job name.

Step 2: Connect to SQL Server database

Connect AWS Transform to your SQL Server database to enable schema analysis and conversion.

Create a database connector

1. In your SQL Server modernization job, navigate to Connect to resources

2. Choose Connect to SQL Server database

3. Choose Create new connector

4. Enter the connector information:

   • Connector name: Descriptive name

   • AWS account ID: Account where SQL Server is hosted

5. Once confirmed, you will receive a link for approval. Copy the approval link to get approval from your AWS admin for the account. Once they have approved, you can proceed to the next step.

6. After your administrator has approved the connector request, click Submit to proceed to the source code connection setup.

Step 3: Connect source code repository

AWS Transform needs access to your .NET application source code to analyze and transform the code that interacts with your SQL Server database. AWS Transform supports three methods for providing source code.

Choose your authentication method

Personal Access Token (PAT) connector (recommended)

Best for teams that need custom permission scopes, self-hosted provider support, or access to provider-specific APIs such as GitHub Secrets. You create a PAT in your source code provider with custom permissions, store it in AWS Secrets Manager, and AWS Transform retrieves it when needed. You are responsible for managing token rotation and expiration.

AWS CodeConnections

Best for teams that want automated credential management. AWS CodeConnections uses a managed provider integration that handles authentication through an OAuth 2.0 authorization flow. AWS manages the entire credential lifecycle, including automatic token refresh and rotation. No manual credential management is required.

Amazon S3

Upload your source code directly to an Amazon S3 bucket. AWS Transform accesses the code from the bucket during the transformation job.

Feature	PAT connector (recommended)	AWS CodeConnections
Credential management	Manual (customer-managed)	Automatic (AWS-managed)
Token lifecycle	Manual rotation required	Automatic refresh
Permission flexibility	Fully customizable scopes	Fixed permissions
Self-hosted provider support	Supported	Not available
Setup complexity	Moderate (manual token creation and storage)	Low (one-time authorization)
Token storage	Customer's AWS Secrets Manager	AWS-managed

Set up a PAT connector (recommended)

With a PAT connector, you create a Personal Access Token in your source code provider with custom permissions, store it securely in AWS Secrets Manager, and AWS Transform retrieves it when needed. You are responsible for managing the token lifecycle including rotation and expiration. AWS Transform automatically creates the necessary IAM role with permissions to access your secret.

PAT connector supports the following providers, including self-hosted and custom DNS/URL versions:

• GitHub and GitHub Enterprise Server

• GitLab.com and GitLab Self-Managed

• Bitbucket Cloud and Bitbucket Data Center

• Azure DevOps and Azure DevOps Server

Create a Personal Access Token

Create a PAT in your source code provider. The required permissions vary by provider. Choose the tab for your provider.

Important

Copy the token immediately after creation. You cannot view it again. Set the expiration for the duration of the transformation job. Do not set the expiration to never expire.

Warning

Never commit PAT tokens to code repositories or share them through insecure channels. Always store them in AWS Secrets Manager.

GitHub

Navigate to Settings, Developer settings, Personal access tokens, Fine-grained tokens. Select the repositories to transform and grant the following permissions.

Repository permissions

Permission	Access	Purpose
Contents	Read and write	Reads source code and writes transformed code back to repository
Metadata	Read-only	Accesses basic repository information

Organization permissions (required for organization repositories)

Permission	Access	Purpose
Members	Read-only	Lists organizations accessible to the token for repository discovery

GitLab

Navigate to Edit Profile, Access Tokens. Select the following scopes.

Scope	Purpose
read_api	Reads repository metadata, project information, user details, and lists groups and branches
read_repository	Reads source code files and repository structure for analysis
write_repository	Writes transformed code back to repository

Bitbucket

Navigate to Account settings, Security, Create and manage API Tokens. The required scopes depend on your token type.

Workspace/Repository Token (ATCT — Bearer auth, no username required)

Permission	Access	Purpose
Repositories	Read and write	Lists repos, reads branches, and writes transformed code via git push

Account API Token (ATAT — Basic auth with email) or App Password (ATBB — Basic auth with username)

Scope	Purpose
read:account	Identifies the authenticated user to resolve repository membership
read:workspace:bitbucket	Lists the workspaces the token can access so AWS Transform can enumerate their repositories. Not required if you specify a workspaces list in the secret.
read:repository:bitbucket	Lists repositories and reads metadata and branch information
write:repository:bitbucket	Writes transformed code back to repository via git push

Azure DevOps

Navigate to User settings, Personal access tokens. Select Custom defined scopes. For organization scope, choose All accessible organizations (recommended) or specify a single organization.

Scope	Access	Purpose
Code	Read & write	Reads source code, lists repositories and branches, and writes transformed code back
User Profile	Read	Validates token access and discovers user identity for organization lookup
Member Entitlement Management	Read	Lists organizations accessible to the token for repository discovery

Store the PAT in AWS Secrets Manager

1. Open the AWS Secrets Manager console.

2. Choose Store a new secret.

3. For Secret type, choose Other type of secret.

4. Add key-value pairs based on your provider and hosting type:

   • Cloud-hosted providers — Add a key named token with your PAT as the value.

     • For Azure DevOps with a specific organization, also add a key named organization with your organization name.

     • For Bitbucket app passwords (ATBB), also add a key named username with your Bitbucket username. For Bitbucket account API tokens (ATAT), add a key named email with your Bitbucket email address.

   • Self-hosted and custom DNS/URL providers — Add the following keys: host (your server URL, for example https://github.mycompany.com), provider_type (github, gitlab, bitbucket, or ado), and token (your PAT).

     • For Azure DevOps with a specific organization, also add a key named organization with your organization name.

     • For Bitbucket app passwords (ATBB), also add a key named username with your Bitbucket username. For Bitbucket account API tokens (ATAT), add a key named email with your Bitbucket email address.

   The following example shows how a secret looks in AWS Secrets Manager for a GitHub cloud-hosted provider:

   {
     "token": "your-github-personal-access-token"
   }

   The following example shows a Bitbucket app password (ATBB):

   {
     "token": "your-bitbucket-app-password",
     "username": "my-bitbucket-username"
   }

   The following example shows a self-hosted GitLab instance:

   {
     "host": "https://gitlab.mycompany.com",
     "provider_type": "gitlab",
     "token": "your-gitlab-personal-access-token"
   }

5. Choose Next.

6. Enter a secret name, for example github-pat-myproject.

7. (Optional) Select a customer-managed KMS key for encryption.

8. Complete the wizard and choose Store.

9. Copy the Secret ARN. You need this value when you configure the AWS Transform job.

If you use a customer-managed KMS key to encrypt your secret (instead of the default AWS-managed key), you must update the KMS key policy to allow AWS Transform to decrypt the secret. Add the following statement to your customer-managed KMS key policy:

{
  "Sid": "Allow AWS Transform to decrypt secrets",
  "Effect": "Allow",
  "Principal": {
    "Service": "transform.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.REGION.amazonaws.com",
      "kms:EncryptionContext:SecretARN": "YOUR-SECRET-ARN"
    }
  }
}

Replace REGION with your AWS Region (for example, us-east-1) and YOUR-SECRET-ARN with the ARN of your secret. The kms:ViaService condition ensures the KMS key can only be used through the AWS Secrets Manager service. The kms:EncryptionContext:SecretARN condition restricts decryption to your specific secret.

To update your KMS key policy:

1. Open the AWS KMS console at https://console.aws.amazon.com/kms.

2. In the navigation pane, choose Customer managed keys.

3. Select your KMS key.

4. On the Key policy tab, choose Edit.

5. Add the policy statement to the existing policy.

6. Choose Save changes.

Note

If you use the default AWS-managed key (aws/secretsmanager), you do not need to modify any KMS key policy.

Configure the AWS Transform job

1. In your AWS Transform job, navigate to Connect to resources.

2. Choose Connect source code repository.

3. Select PAT Connector as the authentication method.

4. Enter the Secret ARN from Step 2.

5. (Optional) Enter the KMS Key ARN if you used a customer-managed KMS key.

6. Select your repository and branch.

7. Choose Continue.

AWS Transform automatically creates an IAM role with the permissions required to access your secret.

Token rotation and maintenance

You are responsible for rotating PAT tokens before they expire. To rotate a token:

1. Generate a new PAT in your source code provider with the same permissions.

2. Update the secret value in AWS Secrets Manager.

3. Verify that your AWS Transform job can access the repository with the new token.

4. Revoke the old PAT in your source code provider.

Troubleshoot PAT connector issues

Access Denied — Invalid PAT

Verify that the PAT has not expired. Confirm that the PAT has the required scopes for your provider. Check that the PAT is correctly stored in AWS Secrets Manager.

Cannot retrieve secret

Verify that the Secret ARN is correct. Check the job logs to confirm that AWS Transform created the IAM role. If you are using a customer-managed KMS key, verify the key policy.

Insufficient permissions

The PAT might lack the required scopes for the operation. Regenerate the PAT with the required scopes and update the secret value in AWS Secrets Manager.

Set up AWS CodeConnections

AWS CodeConnections uses a managed provider integration that automatically retrieves temporary OAuth credentials through an OAuth 2.0 authorization flow. Permissions are configured in the provider app and managed entirely by AWS. You authorize the app once, and AWS handles all credential management.

1. In your SQL Server modernization job, navigate to Connect to resources.

2. Choose Connect source code repository.

3. If you don't have an existing connection, choose Create connection.

4. Select your repository provider:

   • GitHub / GitHub Enterprise

   • GitLab.com

   • Bitbucket Cloud

   • Azure Repositories

5. Follow the authorization flow for your provider.

6. After authorization, choose Connect.

Select your repository and branch

1. Select your repository from the list.

2. Choose the branch you want to transform (typically main, master, or develop).

3. (Optional) Specify a subdirectory if your .NET application is not in the repository root.

4. Choose Continue.

Note

AWS Transform creates a new branch for the transformed code. You can review and merge the changes through your normal code review process.

Repository access approval

For GitHub and some other platforms, the repository administrator must approve the connection request:

1. AWS Transform displays a verification link.

2. Share this link with your repository administrator.

3. The administrator reviews and approves the request in their repository settings.

4. After the administrator approves the request, the connection status changes to Approved.

Important

The approval process can take time depending on your organization's policies. Plan accordingly.

Step 4: Create deployment connector (optional)

If you want to deploy the transformed applications into your AWS account, you have the option to select a deployment connector.

Set up deployment connector

1. Select Yes if you want to deploy your applications. Selecting No will skip this step.

2. Add your AWS account where you want to deploy the transformed applications.

3. Add a name that helps you remember the connector easily

4. Submit the connector request for approval.

Deployment connector approval

Your AWS account administrator must approve the connection request for deployment connector.

1. AWS Transform displays a verification link

2. Share this link with your AWS account administrator

3. The administrator reviews and approves the request in their repository settings

4. Once approved, the connection status changes to Approved

Important

The approval process can take time depending on your organization's policies. Plan accordingly.

Step 5: Confirm your resources

After connecting to your database and repository, AWS Transform verifies that all required resources are accessible and ready for transformation.

What AWS Transform verifies

• Database connectivity: Connection is active, user has required permissions, databases are accessible, version is supported

• Repository access: Repository is accessible, branch exists, .NET project files detected, database connections discoverable

• Environment readiness: VPC configuration supports DMS, required AWS service roles exist, network connectivity established, region compatibility confirmed

Review the pre-flight checklist

1. Navigate to Confirm your resources in the job plan

2. Review the checklist items:

   • ✅ Database connection verified

   • ✅ Repository access confirmed

   • ✅ .NET version supported

   • ✅ Entity Framework or ADO.NET detected

   • ✅ Network configuration valid

   • ✅ Required permissions granted

3. If all items show as complete, choose Continue

4. If any items show warnings or errors, address them before proceeding

Step 6: Discovery and assessment

AWS Transform analyzes your SQL Server database and .NET application to understand the scope and complexity of the modernization.

What gets discovered

• Database objects: Tables, views, indexes, stored procedures, functions, triggers, constraints, data types, computed columns, identity columns, foreign key relationships

• Application code: .NET project structure, Entity Framework models and configurations, ADO.NET data access code, database connection strings, stored procedure calls, SQL queries in code

• Dependencies: Which applications use which databases, cross-database dependencies, shared stored procedures, common data access patterns

Discovery process

• AWS Transform begins discovery automatically after resource confirmation

• Discovery typically takes 5-15 minutes depending on database size and application complexity

• Monitor progress in the worklog

• AWS Transform displays real-time updates as objects are discovered

Review discovery results

After discovery completes, navigate to Discovery and assessment to review:

Database Analysis:

• Object count: Number of tables, views, stored procedures, functions, triggers

• Complexity score: Assessment of transformation complexity (Low, Medium, High)

• Action items: Objects that may require human attention

• Supported features: Database features that will convert automatically

• Unsupported features: Features that require workarounds

Application Analysis:

• Project type: ASP.NET Core, Console App, Class Library, etc.

• .NET version: Detected .NET Core version

• Data access framework: Entity Framework version or ADO.NET

• Database connections: Number of connection strings found

• Code complexity: Assessment of transformation complexity

Dependency Map:

• Visual representation of application-to-database relationships

• Cross-database dependencies

• Shared components

Understanding complexity assessment

AWS Transform classifies your modernization into three categories:

Complexity	Characteristics	Expected Outcome
Low (Class A)	Standard SQL patterns (ANSI SQL), simple stored procedures, basic data types, Entity Framework with standard configurations	Minimal human intervention expected, high automation success rate
Medium (Class B)	Advanced T-SQL patterns, complex stored procedures with business logic, user-defined functions, computed columns	Some human intervention required, expert review recommended
High (Class C)	CLR assemblies, linked servers, Service Broker, complex full-text search	Significant human refactoring required, consider phased approach

Assessment report

AWS Transform generates a detailed assessment report that includes:

• Executive summary with high-level overview

• Complete database inventory

• Application inventory

• Transformation readiness percentage

• Effort estimation

• Risk assessment and mitigation strategies

• Recommended approach

You can download the assessment report for offline review and sharing with stakeholders.

Step 7: Generate and review wave plan

For large estates with multiple databases and applications, AWS Transform generates a wave plan that sequences the modernization in logical groups.

What is a wave plan?

A wave plan organizes your modernization into phases (waves) based on:

• Dependencies between databases and applications

• Business priorities

• Risk tolerance

• Resource availability

• Technical complexity

Each wave contains a group of databases and applications that can be modernized together without breaking dependencies.

Review the wave plan

1. Navigate to Wave planning in the job plan

2. Review the proposed waves

3. For each wave, review:

   • Databases included

   • Applications included

   • Dependencies on other waves

   • Estimated transformation time

   • Complexity level

   • Deployable applications

Customize the wave plan

You can customize the wave plan to match your business needs in 2 ways:

Using JSON:

1. Choose Download all waves to get a JSON file with all the waves

2. Modify waves in the JSON by:

   • Moving databases between waves

   • Splitting waves into smaller groups

   • Merging waves together

   • Changing wave sequence

   • Adding or removing databases from scope

3. Upload the JSON file back to the console by choosing Upload wave plan

4. AWS Transform validates your changes and warns if dependencies are violated

5. Choose Confirm waves to update the wave plan

Using Chat:

You can modify the wave plans by chatting with the agent and asking it to move the repositories and databases to specific waves. This approach works well if you need to make minor edits to the waves.

Important

Ensure that dependencies are respected when customizing waves. Transforming a dependent application before its database can cause issues.

Single database modernization

If you're modernizing a single database and application, AWS Transform creates a simple plan with one wave. You can proceed directly to transformation without wave planning.

Approve the wave plan

1. After reviewing and customizing (if needed), choose Approve wave plan

2. AWS Transform locks the wave plan and proceeds to transformation

3. You can still modify the plan later by choosing Edit wave plan

Step 8: Schema conversion

AWS Transform converts your SQL Server database schema to Aurora PostgreSQL, including tables, views, stored procedures, functions, and triggers.

How schema conversion works

AWS Transform uses AWS DMS Schema Conversion enhanced with generative AI to:

• Analyze SQL Server schemas and relationships

• Map data types from SQL Server to PostgreSQL equivalents

• Transform T-SQL to PL/pgSQL

• Handle identity columns, computed columns, and constraints

• Validate conversion and referential integrity

• Generate action items for objects requiring human review

Supported conversions

Automatically converted:

• Tables, views, and indexes

• Primary keys and foreign keys

• Check constraints and default values

• Most common data types

• Simple stored procedures

• Basic functions and triggers

• Identity columns (converted to SERIAL or GENERATED)

• Most computed columns

May require human review:

• Complex stored procedures with advanced T-SQL

• SQL Server-specific functions (GETUTCDATE, SUSER_SNAME, etc.)

• Computed columns with complex expressions

• Full-text search indexes

• XML data type operations

• HIERARCHYID data type (requires ltree extension)

Not automatically converted:

• CLR assemblies

• Linked servers

• Service Broker

• SQL Server Agent jobs

Start schema conversion

1. Navigate to Schema conversion in the job plan

2. Review the conversion settings:

   • Target PostgreSQL version

   • Extension options (ltree, PostGIS, etc.)

   • Naming conventions

3. Choose Start conversion

4. Monitor progress in the worklog

5. Conversion typically takes 10-30 minutes depending on the number of database objects

Review conversion results

After conversion completes, navigate to Review schema conversion:

Conversion Summary:

• Objects converted: Count of successfully converted objects

• Action items: Objects requiring human attention

• Warnings: Potential issues to review

• Errors: Objects that could not be converted

Review by Object Type:

• Tables: Data type mappings, constraints, indexes

• Stored procedures: T-SQL to PL/pgSQL conversion

• Functions: Function signature and logic changes

• Triggers: Trigger syntax and timing changes

Review action items

1. Choose View action items

2. For each action item, review:

   • Object name: The database object

   • Issue type: What requires attention

   • Severity: Critical, Warning, or Info

   • Recommendation: Suggested resolution

   • Original code: SQL Server version

   • Converted code: PostgreSQL version

3. For each action item, you can:

   • Accept: Use the converted code

   • Modify: Edit the converted code

   • Flag for later: Mark for human review after transformation

Example: Stored procedure conversion

SQL Server T-SQL:

CREATE PROCEDURE GetProductsByCategory
    @CategoryId INT,
    @PageSize INT = 10
AS
BEGIN
    SET NOCOUNT ON;
    
    SELECT TOP (@PageSize)
        ProductId,
        Name,
        Price,
        DATEDIFF(DAY, CreatedDate, GETUTCDATE()) AS DaysOld
    FROM Products
    WHERE CategoryId = @CategoryId
    ORDER BY Name
END

Converted PostgreSQL PL/pgSQL:

CREATE OR REPLACE FUNCTION get_products_by_category(
    p_category_id INTEGER,
    p_page_size INTEGER DEFAULT 10
)
RETURNS TABLE (
    product_id INTEGER,
    name VARCHAR(255),
    price NUMERIC(18,2),
    days_old INTEGER
) AS $$
BEGIN
    RETURN QUERY
    SELECT 
        p.product_id,
        p.name,
        p.price,
        EXTRACT(DAY FROM (NOW() - p.created_date))::INTEGER AS days_old
    FROM products p
    WHERE p.category_id = p_category_id
    ORDER BY p.name
    LIMIT p_page_size;
END;
$$ LANGUAGE plpgsql;

Changes made:

• Procedure converted to function returning TABLE

• Parameter names prefixed with p_

• TOP converted to LIMIT

• DATEDIFF converted to EXTRACT

• GETUTCDATE() converted to NOW()

• Column names converted to lowercase (PostgreSQL convention)

Approve schema conversion

1. After reviewing all action items and making necessary modifications

2. Choose Approve schema conversion

3. AWS Transform prepares the converted schema for deployment to Aurora PostgreSQL

Note

You can download the converted schema as SQL scripts for offline review or version control.

Step 9: Data migration (optional)

AWS Transform provides options for migrating data from SQL Server to Aurora PostgreSQL. Data migration is optional and can be skipped if you only need schema and code transformation.

Data migration options

Option 1: Production Data Migration

Migrate your actual production data using AWS DMS:

• Full initial load of all data

• Continuous replication during testing (CDC)

• Minimal downtime cutover

• Data validation and integrity checks

Option 2: Skip Data Migration

Transform schema and code only:

• Useful for development/testing environments

• When data will be migrated separately

• For proof-of-concept projects

Configure data migration

1. Navigate to Data migration in the job plan

2. Choose your migration option:

   • Migrate production data

   • Skip data migration

3. If migrating production data, configure:

   • Migration type: Full load, or Full load + CDC

   • Validation: Enable data validation

   • Performance: DMS instance size

   • Choose >Start migration

Production data migration process

If you choose to migrate production data:

1. Initial sync: AWS DMS performs full load of all tables

2. Continuous replication: (If CDC enabled) Keeps data synchronized

3. Validation: Verifies row counts and data integrity

4. Cutover preparation: Prepares for final synchronization

Migration Timeline:

• Small databases (< 10 GB): 30 minutes - 2 hours

• Medium databases (10-100 GB): 2-8 hours

• Large databases (> 100 GB): 8+ hours

Data validation

AWS Transform validates migrated data with the following checks:

• Row count comparison (source vs target)

• Primary key integrity

• Foreign key relationships

• Data type compatibility

• Computed column results

• Null value handling

Step 10: Application code transformation

AWS Transform transforms your .NET application code to work with Aurora PostgreSQL instead of SQL Server. It asks for a target branch name in your repositories to commit the transformed source code. Once you enter the branch name, AWS Transform will create a new branch and initiate the transformation to match the PostgreSQL database.

What gets transformed

Entity Framework Changes:

• Database provider: UseSqlServer() → UseNpgsql()

• Connection strings: SQL Server format → PostgreSQL format

• Data type mappings: SQL Server types → PostgreSQL types

• DbContext configurations: SQL Server-specific → PostgreSQL-specific

• Migration files: Updated for PostgreSQL compatibility

ADO.NET Changes:

• Connection classes: SqlConnection → NpgsqlConnection

• Command classes: SqlCommand → NpgsqlCommand

• Data reader: SqlDataReader → NpgsqlDataReader

• Parameters: SqlParameter → NpgsqlParameter

• SQL syntax: T-SQL → PostgreSQL SQL

Configuration Changes:

• Connection strings in appsettings.json

• Database provider NuGet packages

• Dependency injection configurations

• Startup/Program.cs configurations

Start code transformation

1. Navigate to Application transformation in the job plan

2. Review the transformation settings:

   • Target .NET version (if upgrading)

   • PostgreSQL provider version

   • Code style preferences

3. Choose Start transformation

4. Monitor progress in the worklog

5. Transformation typically takes 15-45 minutes depending on codebase size

Step 11: Review transformation results

Before proceeding to deployment, review the complete transformation results to ensure everything is ready for testing.

You can download the transformed code from the repository branch for:

• Local testing and validation

• Code review in your IDE

• Integration with your CI/CD pipeline

• Version control commit

You can also download the transformation summary to review the natural language changes that are made by AWS Transform as part of the transformation.

Transformation summary

1. Navigate to Transformation summary in the job plan

2. Review the overall results:

   • Schema conversion: Objects converted, action items, warnings

   • Data migration: Tables migrated, rows transferred, validation status

   • Code transformation: Files changed, lines modified, issues resolved

   • Readiness score: Overall readiness for deployment

Generate transformation report

AWS Transform generates a comprehensive transformation report:

1. Choose Generate report

2. Select report type:

   • Executive summary: High-level overview for stakeholders

   • Technical details: Complete transformation documentation

   • Action items: List of human tasks required

3. Choose Download report

The report includes:

• Transformation scope and objectives

• Objects and code transformed

• Issues encountered and resolutions

• Validation results

• Deployment readiness assessment

• Recommendations for testing

Step 12: Validation and testing

Before deploying to production, validate that the transformed application works correctly with Aurora PostgreSQL.

Validation types

Automated Validation: AWS Transform performs automated checks:

• Schema validation against source database

• Data integrity verification

• Query equivalence testing

• Connection string validation

• Configuration validation

Human Validation: You should perform additional testing:

• Functional testing of application features

• Integration testing with other systems

• Performance testing and benchmarking

• User acceptance testing

• Security testing

Run automated validation

1. Navigate to Validation in the job plan

2. Choose Run validation

3. AWS Transform executes validation tests:

   • Database connectivity

   • Schema compatibility

   • Data integrity

   • Application build

   • Basic functionality

4. Review validation results:

   • Passed: Tests that succeeded

   • Failed: Tests that need attention

   • Warnings: Potential issues to review

Testing checklist

Database Functionality:

• All tables accessible

• Stored procedures execute correctly

• Functions return expected results

• Triggers fire appropriately

• Constraints enforced properly

• Indexes improve query performance

Application Functionality:

• Application starts successfully

• Database connections established

• CRUD operations work correctly

• Stored procedure calls succeed

• Transactions commit/rollback properly

• Error handling works as expected

Data Integrity:

• Row counts match source

• Primary keys unique

• Foreign keys valid

• Computed columns correct

• Null handling appropriate

• Data types compatible

Performance:

• Query response times acceptable

• Connection pooling configured

• Indexes optimized

• No N+1 query issues

• Batch operations efficient

• Resource utilization reasonable

Step 13: Deployment

After successful validation deploy your modernized application and database to production.

Deployment options

• Amazon ECS and Amazon EC2 Linux

Pre-deployment checklist

Before deploying to production:

• All validation tests passed

• Performance testing completed

• Security review completed

• Backup and rollback plan documented

• Monitoring and alerting configured

• Team trained on new environment

• Stakeholders informed of deployment

• Maintenance window scheduled

Deploy to Amazon ECS

1. Navigate to Deployment in the job plan

2. Choose Deploy to ECS

3. Configure deployment settings:

   • Cluster: Select or create ECS cluster

   • Service: Configure ECS service

   • Task definition: Review generated task definition

   • Load balancer: Configure ALB/NLB

   • Auto-scaling: Set scaling policies

4. Review infrastructure-as-code (CloudFormation template or AWS CDK code)

5. Choose Deploy

Monitor deployment

AWS Transform deploys your application:

1. Creates Aurora PostgreSQL cluster

2. Applies database schema

3. Loads data (if applicable)

4. Deploys application containers

5. Configures load balancer

6. Sets up auto-scaling

Monitor deployment progress and verify:

• Infrastructure provisioning

• Database initialization

• Application deployment

• Health checks passing

• Application accessible

• Database connections working

• Logs showing normal operation

Post-deployment validation

After deployment:

Smoke Testing:

• Verify critical functionality

• Test key user workflows

• Check integration points

• Monitor error rates

Performance Monitoring:

• Track response times

• Monitor database queries

• Check resource utilization

• Review application logs

User Validation:

• Conduct user acceptance testing

• Gather feedback

• Address any issues

• Document lessons learned

Rollback procedures

If issues arise after deployment:

Immediate Rollback:

• Revert to previous application version

• Switch back to SQL Server (if still available)

• Restore from backup if needed

Partial Rollback:

• Roll back specific components

• Keep database changes

• Revert application code only

Forward Fix:

• Apply hotfix to Aurora PostgreSQL version

• Deploy updated application code

• Monitor for resolution

Important

Keep your SQL Server database available for a period after cutover to enable rollback if needed.

Post-deployment optimization

After successful deployment:

Performance Tuning:

• Optimize slow queries

• Adjust connection pool settings

• Fine-tune Aurora PostgreSQL parameters

• Review and optimize indexes

Cost Optimization:

• Right-size Aurora instance

• Configure auto-scaling appropriately

• Review storage settings

• Optimize backup retention

Monitoring Setup:

• Configure CloudWatch dashboards

• Set up alerting

• Enable Enhanced Monitoring

• Configure Performance Insights

Documentation:

• Update runbooks

• Document architecture changes

• Train operations team

• Create troubleshooting guides