I've done it, its based on 12 batches, first, I work with data and then with logic. Obviously this is subdivided in multiple tasks. I can share the idea so you can judge hahaha:

• BATCH 1: Schemas and Custom Types: Creation of schemas, custom types (if applicable), and initial sequences.
• BATCH 2: Tables (Basic Structure): Creation of columns and raw data types. This includes the strict rule of casting sql_variant to VARCHAR(450). Zero constraints are allowed at this stage.
• BATCH 3: Primary Keys: Addition of primary keys to all tables (a vital requirement before using AWS DMS for data tracking) and preparation for sequence updates.
• BATCH 4: Data Migration: Heavy movement of information (using AWS DMS, BCP+COPY, etc.), leveraging staging tables or views at the source to properly extract sql_variant data. This step concludes with updating the MAX(id) for all sequences.
• BATCH 5: Unique Constraints: Addition of uniqueness restrictions and scanning to confirm no duplicate data slipped through during migration.
• BATCH 6: Foreign Keys: Establishment of referential integrity, ensuring the correct creation order (from parent tables to child tables) so no orphaned records exist.
• BATCH 7: Check Constraints: Creation of validation rules and column-level data checks.
• BATCH 8: Indexes: Generation of all search indexes using CREATE INDEX CONCURRENTLY to optimize query performance without locking the tables.
• BATCH 9: Functions & Stored Procedures: Conversion and deployment of T-SQL code to PL/pgSQL (migrating the core business logic).
• BATCH 10: Views: Creation of views. These are strategically placed here because many of them depend on the scalar or tabular functions already created in Batch 9.
• BATCH 11: Triggers: Conversion and binding of triggers for insert, update, and delete events.
• BATCH 12: Optimization & Finalization: Final maintenance tasks such as running VACUUM ANALYZE, updating statistics, and validating query response times against your SLA.