Unless your database schema is trivial, I would think about using an ETL tool if I were you e.g.
Talend is free. Writing a data migration by hand is quite a painful process, especially if you have to apply different rules to data in the target database. You often end running each stage in the process many times and tweaking the code until you finally get your data to migrate correctly. If you don't know much about SQL or the specific features of your two databases, then you may find it a steep learning curve.
Using an ETL tool will make this process of extracting the data, transforming it (if necessary) and loading it into the new DB easier, more maintainable and reproducible.
But if you think your migration is straightforward enough to code by hand, I would start by migrating the data model i.e. the empty tables, including primary/foreign keys, constraints etc. You also need to watch out for things like sequences e.g. PostgreSQL sequences are used to provide unique numeric values for primary key columns. But you must remember to re-set the sequences after your migration so they start counting from the highest value+1 in the corresponding data column.
If your data model is changing significantly, I would suggest you consider setting up a staging area in the target database, and simply copy your source tables and data into there initially. Then you can perform all the transformations and load the data into the target schema on a single platform. But this will of course mean that all your processing is done on the same server which may impact other users.
Stored procedures will have to be re-written. I never use SQL Server but their procedures won't run on PostgreSQL, so you'll need to convert them to a language that PostgreSQL supports.
Finally be prepared to do a lot of ad hoc SQL to check counts of records, ranges of values, etc. And
test everything thoroughly. Once your old system is gone, you're in trouble if you screwed up the data migration.
