Insert statement performance in SQL Server I have the below Insert statement query as part of an stored procedure that is taking some time to be complete (20-30) minutes, when normally in another server with same hardware specifications takes 1-2 minutes

Query:

INSERT INTO [DBO].[cond]
    (
       [LAST_NAME]
     , [FIRST_NAME]
     , [MIDDLE_NAME]
     , [BUSINESS_NAME]
     , [TIN]
     , [date_of_birth]
     , [OCCUPATION]
     , [CTR_TRANSACTION_FK]
     , [CREATED]
     , [CREATED_BY]
     , [LAST_MODIFIED]
     , [LAST_MODIFIED_BY]
     , [CTR_FK]
     , [CUSTOMER_FK]
     , [cust_type_FK]
     , [gender]
     , [naics_code]
     , [name_suffix]
     , [alternate_name]
     , [extra_type]
     , [ID_ISSUING_COUNTRY_FK]
     , [id_issuing_state]
     , [ID_TYPE]
     , [ID_NUMBER]
     , [FLEX_1]
     , [FLEX_2]
     , [FLEX_3]
     , [FLEX_4]
     , [ID_TYPE_OTHER_DESCRIPTION]
     , [person_involved_source]
     , [person_involved_date]
     , [DEPOSITOR]
    )
    OUTPUT
   [INSERTED].[ID]
     , [INSERTED].[customer_FK]
     , [INSERTED].[CTR_TRANSACTION_FK]
     , [INSERTED].[CASHTX_CUSTOMER_FK]
       INTO [#COND_INSERTED]
    SELECT
   [cust].[last_name]
     , [cust].[first_name]
     , [cust].[middle_name]
     , [cust].[COMPANY_NAME]
     , [foi].[identification_number]
     , [cust].[birth_incorporation_date]
     , [cust].[occupation]
     , NTRX.[CTR_TRX_ID]
     , @FilingDateTime
     , @Filer
     , @FilingDateTime
     , @Filer
     , NTRX.[CTR_ID]
     , [cust].[id]
     , [cust].[customer_type_FK]
     , [cust].[GENDER]
     , [cust].[NAICS_CODE]
     , [cust].[SUFFIX]
     , NULL
     , CASE
       WHEN [cashmap].[cb_type] = 'C'
       THEN 'Conductor'
       WHEN [cashmap].[cb_type] = 'O'
       THEN 'Common Carrier'
       ELSE ''
   END
     , [ctry1].[id]
     , [cust].[id_issuing_state]
     , [cust].[id_type]
     , [cust].[id_number]
     , [cashmap].[FLEX_1]
     , [cashmap].[FLEX_2]
     , [cashmap].[FLEX_3]
     , [cashmap].[FLEX_4]
     , [cust].[ID_TYPE_OTHER_DESCRIPTION]
     , 1
     , [cust].[LAST_MODIFIED]
     , [cashmap].[DEPOSITOR]
    FROM  [DBO].[cashcust] AS [cashmap]
      INNER JOIN [DBO].cust AS [cust] ON [cashmap].[CUSTOMER_FK] = [cust].[id]
      LEFT JOIN [DBO].custf AS [foi] ON [foi].[customer_FK] = [cust].[id]
      LEFT JOIN [DBO].country AS [ctry1] ON [cust].[id_issuing_country] = [ctry1].[fincen_code]
      INNER JOIN [DBO].trans AS [TXN] ON [txn].[UNIQUE_TRANS_ID] = [cashmap].[transaction_id]
               AND txn.INSTITUTION_FK=cashmap.INSTITUTION_FK
      LEFT JOIN [DBO].custacc AS [custmap] ON [txn].[account_FK] = [custmap].[account_FK]
                AND [custmap].[mapping_type] = 1
                AND [custmap].[IS_ACCOUNT_HOLDER] = 1
                AND [cashmap].[customer_FK] = [custmap].[customer_FK]
      JOIN [#TMP_INSERTED] AS NTRX ON NTRX.TRX_ID=[txn].[id]
    WHERE  [cashmap].[conductor_bene] = 'C'
      AND @SourceConBenFromTellerFile = 0
      AND ISNULL([cashmap].[has_error], 0) = 0;


Execution Plan:
I noticed that the heaviest operator is the Clustered Index Insert.



Note: First set of inserted row was: 4810
      Second set of inserted row was: 4886
      Third set of inserted row was: 62

So not sure why is taking that time to insert them.    

Important Server Info:
MaxDOP = 4.
Cost Treshold of Parallelism = 5

Top Waittypes:


Page life expectancy  =                                                                                                     60

Also I noticed some implicit conversion warnings in some of the insert statements:



Full Execution Plan:
Part 1:


Part 2:


Part 3:


Memory Clercks for Blocking:
It's hard to be sure what's happening without a sample of data, but I can throw a few ideas out there:


Have you isolated whether the problem is with the INSERT or the SELECT?  It could be that the query is running slower on the one machine, and it's not the insert per se that's the problem.
Do the two servers have the same schema?  I once spent a week tracking a poor performance issue until discovering that I had temporarily deleted an index and forgot to restore it (oops).  There are several good tools for automatically comparing schemas.  For example, if they have the same fields in their clustering index, but in a different order, that could make a big difference.
Do the two tables have similar record counts, fragmentation, and fill factors?  Those shouldn't make a huge difference, but they will affect insert speed.
To avoid the implicit insert, consider writing the result of your SELECT into a temp table, with data types and clustering fields like the target.  Then INSERT from there into your target.  This will let you separate the cost of the INSERT vs the SELECT, and will minimize the time the target table is locked.